Moving off page builders without breaking what works.

Every quarter we get the same call. The founder is on Bubble, or Framer, or Webflow, and it worked beautifully for two years. Then it started to hurt — slow, brittle, painful to change — and they're ready to move. They also have 40,000 users on the live product and a paying customer base that cannot break while the move happens. The question is always some variation of the same thing: do we rebuild, or do we keep patching?

The honest answer, most of the time, is that the choice is false. You don't have to pick between a clean-room rewrite and another year of duct tape. There's a third path, and it's the one we've walked on every migration we've taken on in the last three years. It's less heroic and significantly less expensive than either extreme, and — if you do it right — your users never see the seam.

This post is that playbook.

§ 01The false choice everyone gets stuck on

When a product built on a visual tool starts to hit its ceiling, the founder usually hears two options, both loud and both wrong.

The first is the big-bang rewrite. A new team, a new stack, six quiet months, and a flag-day launch. This is the version that gets written up on Hacker News. It is also, by every measurement we've ever seen, the version that fails — either because the new thing ships too late to matter, or because it ships on time but misses all the edge cases the old platform had silently grown around.

The second is the forever patch. Keep adding plugins, keep hiring consultants who know the quirks of whatever tool you're on, keep eating the workaround tax. This is cheaper week-to-week and almost always more expensive by month twelve.

Rewrites don't fail because they're technically hard. They fail because for six months you have two products — the one your users use and the one your team is building — and only one of them gets feedback.

The third path — the one we push clients toward — is incremental rebuild. You keep the old product running, you put a real codebase alongside it, and you move pieces across one surface at a time. Nothing ships for the first time on launch day, because there is no launch day.

§ 02What a rebuild actually looks like

Concretely: we put a real Next.js or Remix application in front of the existing product using a reverse proxy. For the first few weeks, 100% of traffic still routes to the old stack. The new app is live, but empty. That's the point — we're proving the seam before we build anything behind it.

From there, we pick one route at a time and port it. Usually we start with something small and read-heavy — a blog index, a pricing page, a pricing calculator — because those are low-risk and they exercise every piece of the new pipeline: data fetching, rendering, deploy, cache, analytics, error reporting. If you can ship a blog index well, you can ship a checkout.

[ FIG. 002 ] — Reverse-proxy routing during migration

Once that first route is live and stable for a week, everyone on the team — client side and ours — exhales. Not because the hard part is done, but because the unknown part is done. Every route after that is a repeat of a pattern the team now trusts.

Data first, UI second

The unglamorous truth about these migrations is that the heavy lift is almost never the pages. It's the data. Every page builder accumulates its own schema of custom data types, hidden fields, and workflow state that nobody has mapped for years. Before we move a single route, we map every piece of that schema into a clean Postgres model and start shadow-writing to it. By the time we're ready to port the page that reads it, the data is already correct in the new database.

§ 03Three phases, one running product

We structure every migration into three phases, each shorter than people expect:

1. Shadow. New stack is deployed and receiving traffic through a reverse proxy. Old stack serves every response. We double-write data and double-read for parity checks. Nothing user-visible changes.
2. Shift. Routes migrate one at a time. Each one runs behind a feature flag so we can roll back in under sixty seconds. Both platforms are production simultaneously, and that is fine.
3. Sunset. The old platform has no routes left serving users. We keep it running, read-only, for two more months, then archive the export and shut it off.

§ 04What to preserve, what to throw out

People expect us to arrive with opinions about what their product should become. We don't. We arrive with opinions about what the migration should preserve, which is a much smaller list:

• Every URL. Every live URL must resolve in the new system. Redirects are acceptable; 404s are not. This is non-negotiable for SEO and for every tab that any user has bookmarked.
• Every event. Analytics, auth state, purchase history — the timeline of a user on day 30 must match what they saw on day 29.
• Every workflow. If a merchant could do X in the admin, they can still do X on day one.

What we actively throw out is whatever shape the old tool forced onto the data model. Visual builders encourage schemas shaped like the UI, not the domain, and those schemas get in the way of everything you'll want to do next. We rebuild the model around nouns the business actually talks about.

§ 05The checklist we hand to founders

Before we kick off an engagement, we ask every founder to sign off on a short list. If they can't, the migration isn't ready yet — and that's fine. We've walked two teams off the edge of doing this too early.

# Pre-migration readiness
1. Every live URL is cataloged
2. Staging environment mirrors production traffic
3. Data schema reviewed and versioned
4. Team owns the new stack (or will, by month two)
5. Analytics baseline snapshotted
6. Rollback plan per route, documented

That last one matters more than people realize. Feature flags are not optional on a migration. Every route we move ships behind one, and we've rolled back exactly four times across fourteen migrations. Each of those four would have been an incident if the flag hadn't existed.

§ 06When not to migrate

Most of this essay assumes you should migrate. Sometimes you shouldn't. If the product is still finding its shape, if the traffic hasn't outgrown what the current tool handles, if the team doesn't yet know which parts are load-bearing — stay on the builder. We've told clients this and lost the engagement, and we'd do it again. Rebuilding a product that hasn't found product-market fit is how you lose twelve months.

But once the shape is clear — once you know what the product is, who uses it, and why patching is costing you more than the migration would — the incremental path is almost always available. Your old stack keeps running. A real codebase grows next to it. One route at a time moves across. Your users never see it happen.

That's the whole playbook. It is not glamorous. It also works.

— End of essay. If you're in this position, we'd be glad to look at your stack. Start a project →