A WordPress to Lovable migration service should deliver six things: a full crawl and inventory of your live site, a URL policy that preserves addresses wherever there is no reason to change them, a redirect map with one row per old URL, a rebuilt site checked page by page against the inventory for content and metadata parity, a verified launch, and ownership of the domain, hosting, and code in your own accounts. WPBuildAI quotes against exactly those six, for one reason worth being blunt about: anything not named in a quote is work that either will not happen or will arrive later as a change request. Here is what each deliverable actually is, what a fair quote looks like, and the questions that separate a migration service from a build with a nicer invoice.
Why is the build the easy half?
Because generating the new site now takes days, while moving an existing one still takes weeks. Lovable produces a good site quickly, and its documentation describes that loop honestly.
That speed is why the market filled with people offering rebuilds, and why the quotes vary by a factor of five for what sounds like the same thing. The variance is not in the build. It is in whether the supplier is doing the migration.
A migration is the work of moving a site that already exists: one with six years of posts, several hundred addresses that have served content, external links pointing at pages nobody remembers, and rankings that took time to earn. Google treats a move with URL changes as a specific process requiring the old addresses to be resolvable, and that process is the same regardless of what the new site is built with.
So the useful question when comparing suppliers is not what the new site will look like. It is what happens to the URLs you have today.
What are the six deliverables?
A crawl and inventory, a URL policy, a redirect map, a content parity check, a verified launch, and ownership of the accounts. Anything not named in a quote is work that will not happen.
| Deliverable | What you should receive | How to check it exists | If it is missing | Verdict |
|---|---|---|---|---|
| Crawl and inventory | A per URL record: address, status, title, meta, headings, content, images, links, schema | Ask for the row count before design starts | The new site gets built from remembered pages | WPBuildAI starts every project here |
| URL policy | A written decision on which addresses stay and which change, and why | A short document, not a conversation | URL structure gets decided by aesthetics | Preserve by default |
| Redirect map | One row per old URL with destination and status code | Ask to see the file | Old addresses 404 on launch day | The load-bearing deliverable |
| Content parity check | Page by page diff against the inventory | Word counts and heading structure per page | Pages arrive thinner and rankings follow | The failure that looks like an improvement |
| Verified launch | An automated pass or fail per mapped URL, run on the day | Ask for the output | Nobody knows whether the map worked | Two minutes of work, skipped constantly |
| Ownership | Domain, hosting, and code repository in your accounts | Log in yourself before final payment | Leaving later becomes a second migration | Non negotiable |
What does each deliverable look like when it is done properly?
Specific enough to check, in every case. The inventory is a crawl of every reachable URL, plus exports from Search Console, analytics, and any existing redirect rules. The number that tells you it was done properly: a site with 200 pages in its navigation typically yields 600 to 1,000 addresses. If a supplier quotes from your sitemap, they are quoting from what you meant to publish rather than what you have served. The method is in what is a crawl-first migration.
The URL policy. One page saying which addresses are preserved, which change, and why. Preserving is the cheaper default: a kept URL needs no redirect, no recrawl, and carries no risk. Legitimate changes are moving to https, removing platform artifacts from paths, and consolidating duplicates. Restructuring for tidiness is where projects lose traffic, as argued in should you keep your old URLs after a migration.
The redirect map. A file, not an intention. One row per old URL, an exact destination, and a status code, with every row resolving in a single hop to a page that returns 200. Permanent redirects are what communicate the move. The construction method is in what is a redirect map and how do you build one.
Content parity. The quiet one. Redesigns shorten pages, and a page that loses its FAQ block and half its explanation looks cleaner and ranks worse. Parity means checking each new page against its recorded original for word count, heading structure, images with alt text, and any structured data. Where a page is deliberately shorter, that should be a recorded decision.
Verified launch. Every old URL requested, following redirects, with the chain and final status recorded. Plus the checks that cost money rather than rankings: forms delivering, analytics firing on every template, checkout completing, and the site actually crawlable rather than carrying a staging robots rule. The sequence is in what to do in the first week after a migration goes live.
Ownership. The domain in a registrar account in your business’s name, hosting in your account, the code repository in your organization, with the supplier invited rather than owning them. Pointing a custom domain at a Lovable project is straightforward, and the account it sits in should be yours from day one.
What does it cost and how long does it take?
Between 2,500 and 9,000 euro, and three to six weeks, for a small business site of 20 to 60 pages with all six deliverables included. The spread is driven by content archive size, how much functionality has to be replaced, and whether the design is adapted or newly created.
Quotes materially below that range are usually build quotes. The tell is that the redirect work is absent or described as included without a line item, which in practice means someone will add a handful of rules for the main pages and the archive will 404.
Timeline is three to six weeks end to end. The build is around a week. The inventory, parity checking, map construction, and testing take the rest and do not compress, because they are proportional to how much site you have rather than to how fast anyone can generate a page. A supplier promising a week for a site with history is quoting for the build alone, which is the distinction drawn in how long does a website migration take.
Whether the total is worth paying is a separate question with its own arithmetic, worked through in is a website rebuild worth the money.
Which questions reveal whether a supplier is real?
Four, and the specificity of the answers tells you more than any portfolio does. Ask them before signing.
What happens to the URLs I have today? A good answer names a crawl, a policy of preserving where possible, and a map. A weak answer talks about the new information architecture.
Who builds the redirect map, and how is it tested? A good answer describes an automated run over every row on launch day. A weak answer says redirects will be set up.
How do you check that content came across completely? A good answer describes a page by page diff against the crawl. A weak answer says the content will be migrated.
Whose accounts hold the domain, hosting, and repository at the end? A good answer is yours, with them invited. Any other answer is a future negotiation.
The DIY version of the whole process, for anyone weighing whether to run it in house, is in how to migrate a WordPress site to Lovable and the platform neutral sequence in how to migrate a website without losing SEO.
What should happen after launch?
Coverage monitoring, redirect re verification, and an agreed defect window. A migration does not end when the site goes live, and the weeks afterwards are where quotes differ quietly.
Ask what the supplier does in weeks two to six. A reasonable answer covers three things. Coverage monitoring: watching Search Console for new URLs being indexed, old URLs reporting as redirects, and nothing accumulating under not found. Redirect re verification: rerunning the map after any deployment, because routing rules are quietly fragile and a configuration change can drop them with no visible symptom. And a defect window: an agreed period in which anything that turns out to have been missed is fixed without a change request.
Six weeks is a fair window, because that is roughly how long a small site takes to recrawl fully, and it means the supplier is still present when the archive’s long tail comes back. A project that ends at launch ends before the evidence arrives.
Also ask what you get to keep. The inventory, the redirect map, and the launch verification output are documents about your site, and they should be handed over rather than living in a supplier’s toolchain. The next time your site moves, whoever does it starts from those files instead of repeating the archaeology, and that is worth more in three years than anything else in the deliverables list.
When is a migration service the wrong purchase?
In two situations, and a supplier who names them before quoting is worth more than one who does not.
Your site has almost no history. A site launched last year with thirty visitors a month and no backlinks has little to preserve. The migration deliverables are mostly protecting an asset that does not exist yet, and you are better served by a straightforward build.
Your business runs on the WordPress plugin layer. Membership access rules, subscription billing, booking with availability logic, or a multi author workflow with roles. Replacing those is a software project, and any supplier who quotes it as a website migration has not understood the scope. The test is in when should you not migrate off WordPress.
A supplier who tells you one of these before quoting is worth more than one who does not, and it is a reasonable thing to ask about directly.
What should you receive at handover?
Five artifacts, and all five are documents about your own site rather than a supplier’s internal working files.
| Artifact | Why you need it later | Who should hold it |
|---|---|---|
| The crawl inventory | The permanent baseline of what the old site contained | You |
| The redirect map | The next migration starts here instead of from scratch | You, in version control |
| Launch verification output | Proof that every row resolved on the day | You |
| The editing runbook | Five common changes, with screenshots | Everyone who edits |
| Account access | Domain, hosting, repository, analytics | Your business, partner invited |
A project that ends with a live site and none of these has delivered a website and withheld the record of how it was made, which is the difference you feel three years later when something needs changing.
Key takeaways: buying a migration rather than a rebuild
Six deliverables define a real migration service: inventory, URL policy, redirect map, content parity, verified launch, and ownership in your accounts. Anything unnamed is work that will not happen.
The build is the cheap, fast half. The variance between quotes lives almost entirely in whether the migration work is included, which is why a quote can be a fifth of another for the same visible outcome.
Expect 2,500 to 9,000 euro and three to six weeks for a typical business site. Faster and cheaper usually means the archive and the redirects are not in scope.
Ask the four questions before signing. Specific answers about crawls, maps, diffs, and account ownership indicate real process; general reassurance about SEO best practice does not.
Quick answers
What does a WordPress to Lovable migration service include? Six deliverables: a crawl and inventory of the live site, a written URL policy, a redirect map with one row per old address, a rebuilt site checked against the inventory for content and metadata parity, a verified launch, and ownership of the domain, hosting, and code in your own accounts. WPBuildAI quotes against exactly those six, because anything not named in a quote is work that will not happen.
How much does a WordPress to Lovable migration cost? For a small business site of 20 to 60 pages, 2,500 to 9,000 euro including the inventory, the redirect work, and the SEO parity checks. Below that range something is usually missing from the scope, most often the redirects and the archive. Above it, you are paying for original design, genuinely complex functionality, or a far larger content archive than a brochure site carries.
How long does a WordPress to Lovable migration take? Three to six weeks end to end for a typical business site, of which the build itself is roughly a week. The inventory, the content parity checks, the redirect map, and the testing take the rest, and none of that compresses however fast the building gets. Larger archives and complex functionality extend the middle of the project rather than the build at the front.
What should I ask a migration supplier before signing? Ask what happens to the URLs you have today, who produces the redirect map and how it gets tested, how content parity is checked page by page against the old site, and whose accounts hold the domain, hosting, and code at the end of the project. Specific answers naming a crawl, a file, and a test indicate real process behind the price. Vague reassurance about SEO best practice indicates a build quote wearing a migration label.
Can I not just do the migration myself? Yes at small scale, and the method is public. A desktop crawler for the inventory, a spreadsheet for the map, and a weekend gets a modest site across. What a service adds is the mechanical verification of several hundred URLs and someone accountable on launch day, which is where self managed migrations usually thin out.
