Migrating off Bubble: what transfers and what you rebuild
When you migrate off Bubble, your data comes with you and your application logic does not. Bubble documents both sides: user data exports as CSV or through the Data API, and the app itself cannot be exported as code. That split sets the real cost of leaving, and it has nothing to do with whether Bubble is any good.
What actually transfers when you leave Bubble?
Three things behave differently, and knowing which is which turns a vague fear into a scoped project.
Your data transfers. Bubble's application and data ownership page describes exporting user-created data as CSV files, and using the Bubble API to script a more automated way to reach the same data. For most teams this is the part they worried about most and it is the part that is genuinely solved.
Your design transfers partially. Bubble says it can help export the design, which in practice means you keep the visual reference and the screen inventory. You do not keep the components.
Your logic does not transfer. Every workflow, condition, privacy rule and scheduled job was authored in Bubble's editor and runs on Bubble's runtime. Those get rebuilt.
Why can't the application logic come with you?
Because you own what you made, and Bubble owns what it made. The documentation uses a plain comparison: Microsoft owns Word, you own the documents you write in it. Your app is the document, the runtime is Word.
That boundary is deliberate. It also comes with a safeguard most people never read: Bubble states that if the company ceases operations, its source code would be released under an open-source license so apps could keep running.
So the honest framing is simpler than the lock-in story. Bubble is a runtime, and a runtime you did not write is one you cannot take with you. Every platform in this category works the same way.
When does staying cost more than rebuilding?
When the platform starts making decisions that should be yours. Two of them are worth watching, and both are documented.
The first is metered work. Bubble bills server-side work in workload units, and the pricing FAQ puts the base overage at $0.30 per 1,000 units when you have no workload tier subscription. On its own this is a line item. The problem is that it scales with how your app was built, not with how much revenue it produces, so inefficient workflows quietly become a recurring bill.
The second is harsher. The same page describes what happens when overages are disabled and the app hits its limit: it goes offline, and comes back at the start of the next billing period. Availability becomes a function of a billing setting.
What makes this an architecture question rather than a pricing question is where the consumption comes from. Bubble's workload guide says it tracks twelve activity types, and that the same work can run client-side or server-side depending on how the app was built. Two apps serving identical traffic can bill very differently because someone chose a search over a lookup, or moved a calculation to the server without needing to.
Neither fact means you should leave. They mean the decision has a deadline attached to it, and the deadline is set by your growth curve, and that some of that curve is under your control before you ever consider migrating.
How do you scope the rebuild without guessing?
Count the logic. Screen count is the number teams reach for because it is visible, and it is the number that misleads them.
Inventory four things instead: workflows and their branches, external API connections, data types with their relationships, and permission rules per role. That list is the actual surface area of the rebuild, and it is usually much smaller than the screen count suggests, because a large share of screens are variations on the same handful of operations.
The gap shows up fast once you count. Picture an operations app with sixty pages, a number big enough to stall the conversation. Counting the logic underneath it will typically surface a fraction of that in workflows, a handful of integrations, and a short list of roles. You scope the rebuild against the workflows. The pages become a design task, and design is cheap next to logic that has to be reasoned about twice.
This is also the moment to decide what not to rebuild. Systems that grew inside a visual editor accumulate workflows that exist because someone needed them once. Migrating is the rare license to delete them.
What does the migration look like in practice?
It runs in a sequence. Getting that order right matters more than which stack you land on.
Export and model the data first. The CSV and API paths give you the records, but records are not a schema. What arrives is Bubble's data structure, and rebuilding it as-is imports the constraints you were trying to escape.
Three questions separate the real model from its accidents. Which fields exist because the business needs them, and which exist because a workflow needed somewhere to put a value? Which lists should have been relationships? Which option sets grew into what is really a table? Answering those before writing any schema is the single decision with the longest tail, because everything built afterward inherits it.
Then rebuild the logic against the inventory. Run both systems in parallel on real work before cutting over, because the failures that matter are the ones nobody documented.
Parallel running earns its cost only when you compare outputs. Pick the numbers the business already trusts, the ones that appear in a report someone reads every week, and reconcile them between the two systems until they agree. Disagreements are the specification nobody wrote down.
Two of our cases show different shapes of this. In the Colo Saúde platform the first move was to stay: the app was stabilized on Bubble and its consumption cut by 60 percent, and only then did the rebuild on Next.js and Supabase begin. In the UniTrust brokerage system the work went the other way, toward a system built to hold the operation of a US insurance business.
What decided each path was runway: how long the operation could hold while the rebuild happened.
Frequently asked questions
Can I export my Bubble app's source code?
No. Bubble's documentation states that apps run only on the Bubble platform and that there is no way to export the application as code. You can export your data, and Bubble offers help exporting the design, but the logic is rebuilt.
Does migrating mean rewriting everything at once?
No, and doing it that way is the most common mistake. The safer pattern is to rebuild the logic against an inventory, run the new system in parallel with the old one on real work, and cut over per workflow rather than per app.
Will my data survive the move?
Yes. This is the well-documented part: CSV export and the Bubble API both reach your records. The risk sits elsewhere: carrying the old data model across unchanged and inheriting every limit it was shaped by.
Next step
If you are weighing this decision and want a second reading of your own inventory before committing to a plan, book a diagnostic and we will go through it with you.
Read next
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic