Most arguments about migration quality get lost in the weeds — frameworks, block APIs, which plugin does what. So let me skip the weeds and give you the test that actually matters:
If the deliverable can’t survive us going out of business tomorrow, it isn’t done.
That’s the whole standard. Everything below is just what that standard forces you to ship — and what it forces you to refuse.
What every delivery includes
We hand over three artifacts on every project: a theme zip, a plugins zip, and a seed-content zip. Drop them on any host, run the importer, and you have the site. No accounts to create, no proprietary dashboard to log into, no umbilical cord back to us. Three files and a host you control.
Inside that handoff:
- A native block theme with real templates and template parts. Not a page exported as HTML. A proper theme that WordPress understands as a theme — headers, footers, and page structures that the editor can actually edit.
- Custom post types for any structured data the app showed. If the prototype listed services, staff, properties, or events, those become real content types with real fields. Adding the next one is a content task, not a code change.
- A
theme.jsonmirroring your design tokens. The colors, spacing, and typography from the original, encoded so the editor enforces them. The design system ships as part of the build, not as a memo. - Seed content so the staging install looks like the prototype on first load. You open the new site and it’s already populated — not an empty theme you have to imagine filled in. What you saw in the demo is what loads.
- A short Loom walkthrough of the admin. Five minutes showing where everything lives and how to change the things you’ll want to change. The site is editable; this is how you learn that it’s editable.
That’s the short list. It’s short on purpose. A clean migration shouldn’t need a fifty-page manual — it should need a host, three zips, and five minutes of video.
What we refuse to ship
The refusals matter more than the inclusions, because this is where the shortcuts live. Each of these is something a faster, cheaper “migration” will happily hand you — and each one is a trapdoor.
- Page-builder dependencies that lock the site to one editor. The day that plugin changes its pricing, gets acquired, or simply breaks on a WordPress update, your site is hostage. We build on native blocks so the platform itself is the dependency.
- Iframed embeds of the original prototype. Wrapping your Lovable app in an iframe and pointing WordPress at it is not a migration. It’s a redirect wearing a costume. Your prototype is still doing all the work, and you still can’t edit any of it.
- Single-blob HTML pages disguised as a theme. The classic clone: a screenshot of a page pasted into one block. Looks right, edits like granite. We’ve written about why that’s the core failure mode — it’s the single most common thing sold as “WordPress” that isn’t.
- Licenses the client doesn’t own outright. If any part of the deliverable depends on a license in our name, you don’t own your site — you’re renting it from us. That fails the survival test by definition.
The principle underneath the checklist
Lists are easy to follow and easy to game, so here’s the thing the list is really protecting.
A website is an asset, and an asset you don’t fully control isn’t fully yours. Every item on the “refuse” list is a hidden dependency — on a vendor, on a plugin author, on us — that turns ownership into rental. The “include” list is just the inverse: each artifact is a piece of making sure that when we walk away, nothing walks away with us.
Portable, native, owned. If a deliverable misses any of the three, the migration isn’t finished — it’s leased.
This is also why the standard is phrased as a stress test rather than a feature list. Features change. WordPress changes. What doesn’t change is the question: if the people who built this vanished tomorrow, would the client still have a working, editable, fully-owned site? If yes, we shipped. If no, we have more work to do — no matter how good the screenshot looks.
That’s the bar. Everything else is implementation.
Lowpable rebuilds vibe-coded apps from Lovable, Bolt, and v0 into production WordPress you actually own — native theme, real content types, three portable zips. Zip in, zip out. See a live demo or get a quote.