Planning and budgeting an AI to WordPress project: an IT consultant's method
How to scope, estimate and schedule an AI website to WordPress migration realistically, from inventory to launch and aftercare.
Convert2WP – convert your AI website to WordPressClick here
Start with scope, not with tools
Whenever someone asks me what a migration costs, my honest answer is: it depends on what is behind the pages. Two sites with identical homepages can differ by a factor of ten in effort. One is a brochure with eight pages and a contact form. The other has members, payments, a multilingual blog and three integrations with external services.
So I do not start by choosing tools. I start by writing down what the site does. Every function gets one line: what it does, who uses it, how often, and what happens if it breaks. That list is the basis of every estimate I give.
The four buckets of work
I group the work into four buckets. The first is page conversion: turning the visible design and content into WordPress pages and a theme. With a converter this bucket is small and predictable. The second is content modelling: deciding what becomes a page, a post, a custom post type or a taxonomy. The third is functionality: forms, accounts, shops, search, integrations. The fourth is launch and aftercare: redirects, SEO checks, training and monitoring.
Clients are often surprised that the first bucket is the cheapest. The design is what they see, so they assume it is the most work. In my experience it is the third bucket that drives the budget, and that is exactly where honest estimates matter.
Estimating functionality realistically
For each function I choose the simplest reliable WordPress solution. A contact form with email notification is a short task with a form plugin. A newsletter signup connected to a mailing service is similar. A shop with a few products, standard shipping and one payment provider is a few days with WooCommerce. A members area with paid levels, protected content and renewals is more, because it needs careful testing of every scenario.
I add a buffer of around twenty percent to functionality estimates. Not because I expect problems, but because small decisions always appear: an extra email template, a field that the old system had and nobody mentioned, a tax rule for one country.
Timeline: a typical small business project
For a site of roughly ten to thirty pages with a form and a blog, my usual schedule looks like this. In the first days I do the inventory and crawl, confirm the content model and set up hosting with a staging environment. Then I convert the pages and build the theme settings. After that I rebuild the functions, import posts and set up redirects.
The following phase is review: the client checks every page on staging, we fix the small glitches and I run technical SEO checks on the raw HTML. Launch itself takes an hour. Then come eight weeks of light aftercare with weekly checks in Search Console.
Hosting and running costs
A frequent reason for migrating is cost. AI platforms often charge per seat, per project or per usage. WordPress itself is free, but good hosting is not something to save on. I recommend managed WordPress hosting with daily backups, staging, PHP 8 and a CDN. For a small business this usually costs less than the combined subscriptions of an AI builder plus extra services.
Plugins can be free or paid. I keep the list short and prefer plugins with an active development history. Every plugin is a dependency that needs updates, so fewer is better.
Risks I always name in the proposal
I write three risks into every proposal. First, rankings may fluctuate for several weeks after launch; that is normal. Second, backends and databases are not converted automatically; they are rebuilt. Third, small visual differences are expected after conversion and are fixed during review.
Naming these risks in writing does not scare clients. It builds trust, because when one of them occurs, it was expected and there is already a plan.
Measuring success
I agree on a few measurable goals before starting: all important URLs return status 200 or a correct redirect, every page has a unique title and canonical in the server HTML, editors can publish without help, and loading time is equal or better than before. When those goals are met, the project is a success, regardless of whether one icon is a pixel off.
Good planning makes a migration feel boring, and boring is exactly what you want when your business depends on the website.