Startups & MVPs
Migrating off Bubble to real code: when it’s worth it and how to do it without losing users
By Waleed Siddiqui, founder & lead engineer
Bubble is a good way to find out whether anyone wants your product. Many successful SaaS companies started on no-code, and if your app works and costs are under control, you should probably stay. But there is a point where the platform starts to cost more than it saves, and founders usually reach it at an awkward moment: with paying customers, live subscriptions and data that cannot be lost.
We recently moved a subscription membership platform off Bubble onto Next.js and Supabase — members, gated content, an admin portal, tiered Stripe billing and a two-way CRM sync (case study). This guide is what we learned, written for the founder deciding whether to do the same.
Signs you have outgrown Bubble
None of these alone means "migrate now". Three or more usually does:
- Workload costs grow faster than revenue. Bubble bills server work in workload units; data-heavy pages and scheduled workflows can make each new customer more expensive to serve.
- Billing edge cases are handled by hand. Upgrades, downgrades, failed payments and refunds need someone to fix records manually.
- Security lives in the interface. Paid content or other customers' data is "hidden" on the page rather than protected by rules on the server.
- Integrations drift. Your CRM, email tool and app disagree about who is a paying customer.
- Investors or enterprise buyers ask about the stack. Due diligence questions about code ownership, testing or security reviews are hard to answer.
- You cannot hire for it. You want engineers to own the product, and the work they want to do does not fit in a visual editor.
What you can and cannot take with you
Bubble's own support documentation is clear: there is currently no way to export your application as code. In practice:
| Asset | Carries over? | How |
|---|---|---|
| Your data | Yes | CSV export per data type, or Bubble’s Data API (a REST/JSON API over your database) for scripted extraction |
| Users | Yes, but not passwords | Import the accounts; users set a new password or sign in by email link on first visit |
| Stripe customers and subscriptions | Yes — they live in Stripe, not Bubble | Link existing Stripe customer and subscription IDs to the new user records; nobody re-enters a card |
| Files and images | Yes | Download from Bubble’s storage and re-upload, rewriting the URLs stored in your data |
| Workflows and logic | No | Rebuilt as code; your Bubble editor is the specification |
| Design | Partly | Recreated in code; a good moment to fix what users complain about |
The good news hiding in that table: the two things founders worry about most — customer data and paying subscriptions — both move without customers having to do anything except, at most, set a new password.
A migration plan that keeps the business running
- Inventory the app. List every page, workflow, scheduled job, API connection, privacy rule and data type. Bubble's editor is your spec; anything not on the list will be forgotten.
- Design the new data model — do not copy the old one. Bubble data types often carry years of workarounds. Map each one to clean tables, decide which fields die, and write the access rules (we enforce them in the database with row-level security).
- Rebuild in parallel. The Bubble app stays live while the new one is built and tested against a copy of real data.
- Write the migration as code, and run it many times. One script extracts from Bubble, transforms and loads into the new database. Rehearse it on fresh exports until it runs cleanly end to end.
- Reconcile. Compare counts and totals between old and new: users, active subscriptions, content items, balances. Every mismatch gets a fix in the script, not by hand.
- Freeze, final run, switch. Pick a quiet window, pause writes in Bubble, run the final migration and reconciliation, point the domain and Stripe webhooks at the new app, and email users how to sign in.
- Keep Bubble read-only for a few weeks. If a record looks wrong, you can check the original.
On the membership platform, the migration was a dedicated migration function plus around 25 reconciliation and backfill scripts — most of them for Stripe: matching prices to plans, re-linking subscriptions and carrying over trial end dates. That ratio is typical. Moving rows is easy; making billing state agree everywhere is the real work.
Moving Stripe subscriptions without re-billing anyone
Stripe holds the subscriptions, so you are not moving them — you are teaching the new app which Stripe objects belong to which user. The checks we run:
- Every active Stripe subscription maps to exactly one user in the new database, and vice versa.
- Every Stripe price maps to a plan in the new app, including legacy prices that old customers still pay.
- Trial end dates, scheduled cancellations and pending downgrades are preserved.
- The new webhook handler is idempotent before it goes live, because switching endpoints can replay events — see our guide to Stripe subscription webhooks.
- The old Bubble workflows that reacted to Stripe are switched off at cut-over, so the two apps never both act on the same event.
What to migrate to
There is no single right answer, but for most Bubble apps we recommend a stack that keeps the "fast to build" feel while giving you real code:
| Layer | Our usual choice | Why |
|---|---|---|
| Web app | Next.js (React, TypeScript) | Large hiring pool; server rendering for public pages |
| Database and auth | Supabase (Postgres) | Relational data, row-level security, built-in auth and storage |
| Payments | Stripe (kept as is) | Nothing to migrate for customers |
| Hosting | Vercel or Netlify | Preview deployments for every change |
If you would rather keep a visual tool for parts of the product, a hybrid is possible: move the database and business logic into code first, and leave internal admin screens on a low-code tool until they need more.
What a migration costs
A migration is a rebuild plus a data project, so it costs roughly what building the product's current feature set would cost, plus the migration and reconciliation work. It is usually less than the original build in one way: the product decisions have already been made, and the Bubble app answers most questions.
The biggest cost drivers are the number of workflows, how messy the data is, billing complexity and integrations. For reference, our SaaS and MVP builds start at $38,500; we give a fixed price for a migration after reviewing the app and a data export.
