How to migrate off AI app builders.

Per-platform notes

The 10-step framework is platform-agnostic, but the hard parts move depending on where you're coming from.

Lovable → Next.js

The cleanest migration. Lovable syncs to GitHub; the Supabase project is already portable. The work is in the frontend (React drift, inconsistent state management), the auth wiring (Supabase SSR conventions have evolved), and the RLS audit that should have happened before launch. Typical timeline: 4 weeks for an MVP, 6 weeks if Stripe and email need hardening. Our fixed fee: $9,999.

Bolt.new → Next.js

Medium effort. The download-zip path looks like an export but the WebContainer has already shaped the code — auto-injected env vars, permissive CORS, pre-wired Supabase credentials. Every integration needs to be re-verified against a real Netlify or Vercel runtime. We usually regenerate the frontend in v0 or write it by hand while keeping the Supabase schema. Timeline: 4–6 weeks.

Base44 → Next.js

The hardest migration because there's no source export. You get data exports (entity schemas, rows) but the application code is platform-hosted and not portable. In practice, Base44 → Next.js is a rebuild informed by the old screens, not a migration in the normal sense. Timeline: 6–8 weeks; cost closer to $20,000 for anything beyond the simplest app.

Replit Agent → Next.js

Files are portable — that part is easy — but Replit-specific services are not. Nix package declarations need to be replaced with standard npm/pnpm, Secrets need to be moved into Vercel, and the built-in Postgres needs to become Supabase or Neon. Timeline: 3–5 weeks for standard apps.

The data cutover checklist

The single moment the migration can fail irreversibly is the data cutover. Run it like a rehearsed play:

1. Freeze writes on the source system. Put the old app in read-only mode via a feature flag or a maintenance banner. Writes that land here after this point will be lost at cutover.
2. Take the final snapshot. pg_dump for Postgres, CSV + schema for Base44 entities, JSON for Replit KV. Store the snapshot in two locations before proceeding.
3. Load the snapshot into the new system. Run count-and-checksum diffs on every table. Counts must match exactly; checksums on any column set that includes created_at, updated_at, user_id, and money columns must match.
4. Reconcile integrations. Stripe subscription status via the Stripe API against your new DB. OAuth tokens re-verified. Any queue-based integration (SQS, webhooks) re-pointed at the new endpoint.
5. DNS switch and SSL.Lower TTL 24 hours before the cutover. On cutover, flip the DNS, verify SSL, smoke test every auth flow within 10 minutes. Rollback plan is “flip DNS back” — have it tested.
6. Post-cutover monitoring. Error rate watched hourly for 48 hours, a support path on standby for the edge cases the rehearsal missed, and a rollback trigger (error rate above a threshold) that can be pulled without meeting.

Preserving SEO and auth

Two quiet failure modes. SEO: every URL that changes must have a 301 redirect on the new host, your sitemap must be re-submitted to Search Console within 24 hours of cutover, and canonical tags must point at the new URL exclusively. Google will forgive a 301 chain; it will not forgive a 404. Auth:session cookies from the old host won't survive, so plan for users to sign in again. Password hashes are portable across Supabase projects; OAuth tokens are not. The cleanest experience is a one-time passwordless link on cutover day, which sidesteps both problems.

A decision tree

If you're undecided about whether to migrate now or later, run through this:

1. Are you paying more in platform credits than an engineer would cost? Migrate.
2. Has an investor or acquirer asked for portable code? Migrate.
3. Do you need SOC 2 or HIPAA in the next 12 months? Migrate.
4. Is your app hitting performance limits the builder can't address? Migrate.
5. Are none of the above true and the app works? Stay. Re-ask in 90 days.

The worst migration timing is after an incident that could have been prevented. The best is when the app is small enough that the schema fits in a single head and you're not yet locked into platform-specific conveniences. We've migrated apps at both stages; early is cheaper.

See also: app migration service · migrate prototype to production · Lovable → Next.js escape plan