# Migrating from Bubble to custom code: how to decide > Leaving Bubble is a scoping problem, not a loyalty test. What the platform documents about ownership, what drives the rebuild cost, and how to run the move. - Author: Marlon Trettin - Published: 2026-08-21 · Updated: 2026-08-21 - Language: en - Canonical: https://yowpi.com/en/blog/migrating-from-bubble-to-custom-code --- Migrate from Bubble to custom code when the platform starts deciding things that should be yours: what your app costs to run, when it goes offline, how fast you can change it. The trigger is not disappointment with Bubble. It is the point where your business logic outgrew a runtime you do not control. ## TL;DR - Your data leaves with you. Bubble documents [CSV export and an API](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) for it. Your application logic does not leave, because it cannot be exported as code. - The rebuild is priced by how much logic you accumulated, not by how many screens you have. - Two documented limits decide the deadline: metered workload billed at [$0.30 per 1,000 units](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) without a tier, and an app that goes offline when it hits the limit with overages disabled. - Run both systems in parallel on real work before cutting over. The failures that matter are the ones nobody documented. ## When is it actually time to leave Bubble? When the platform starts making decisions that belong to you. Bubble is good at what it is for, and most apps that leave it should never have left earlier than they did. The question is not whether the tool is good. It is whether you still control the variables your business depends on. Three signals matter, and only one of them is about money. The first is metered work. Bubble bills server-side activity in workload units and its [pricing FAQ](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) sets the base overage at $0.30 per 1,000 units when you have no workload tier subscription. On its own that is a line item. It becomes a problem because consumption tracks how the app was built rather than how much revenue it produces, so an inefficient workflow quietly becomes a recurring bill. The second is harsher and sits on the same page. When overages are disabled and the app reaches its limit, Bubble states the app is taken offline and comes back at the start of the next billing period. Availability becomes a function of a billing setting. The third has no number attached. It is the moment your team stops proposing changes because changing anything has become expensive or risky. That one usually arrives before the other two and gets noticed after them. ## What does Bubble let you take with you? Data, yes. Design, partly. Logic, no. Bubble is unusually clear about this, and reading the actual documentation beats the lock-in folklore. On ownership, Bubble states that you own your data, including your app's design and anything your users uploaded, while [Bubble retains ownership of the underlying code](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) that powers the app. On export, the same page is blunt: Bubble apps run only on the Bubble platform, and there is no way to export the application as code. For data it documents automatic CSV export and the Bubble API for scripted access. It also says the company will help you export the design and will do its best to help you leave. There is even a safeguard most people never read: if Bubble ceased operations, its source code would be released under an open-source license so apps could keep running on a self-hosted Bubble server. So the honest framing is simpler than the horror story. A runtime you did not write is one you cannot take with you. Every platform in this category works the same way. What splits an easy migration from a hard one is how much of your business logic you put inside it. The detail of that split is in [what transfers when you migrate off Bubble](/en/blog/migrating-off-bubble-what-transfers). ## What actually drives the cost of the rebuild? The logic, not the screens. 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 real surface area, 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. This is also the moment to decide what not to rebuild. Systems that grew inside a visual editor accumulate workflows that exist because somebody needed them once. Migrating is the rare license to delete them, and deleting is the cheapest work in the whole project. One caveat on the workload side: Bubble tracks [twelve activity types](https://manual.bubble.io/help-guides/workload/understanding-workload) that feed the monthly total, and the same feature can consume very differently depending on how it was built. Some of your bill is architecture rather than destiny, which means part of the pressure to migrate can be relieved before you migrate. ## How do you move without stopping the operation? In a sequence, and getting the order right matters more than which stack you land on. Export and model the data first. CSV and the API give you the records, but records are not a schema. What arrives is Bubble's data structure, and rebuilding it unchanged 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? Then rebuild the logic against the inventory, and run both systems in parallel on real work before cutting over. Parallel running only earns its cost when you compare outputs: pick the numbers the business already trusts, the ones in a report someone reads every week, and reconcile them between the two systems until they agree. The disagreements are the specification nobody wrote down. Two of our cases show different shapes of this. In the [Colo Saúde platform](/en/cases/colo-saude) 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](/en/cases/unitrust) the work went 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. ## What do you give up by leaving? Speed of change, at least at first. In Bubble a small edit is minutes. In a custom system it goes through a developer and a release. Anyone who tells you otherwise is selling something. You also give up a hosting story that someone else maintains, and you take on decisions about infrastructure you previously did not have to make. That is a real cost and it belongs in the comparison honestly. What you get back is control of the three variables above: what it costs to run, whether it stays online, and how far it can grow. For an app that is still finding its shape, that trade is usually bad. For an operation that a business already depends on, it usually is not. ## 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. 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. **Should I fix the app on Bubble first, or just leave?** Often fix first. If workload cost is the pressure and the app was built inefficiently, part of that bill is architecture rather than platform. Stabilizing buys runway, and runway is what decides whether the rebuild is calm or rushed. ## Next step If you are weighing this decision and want a second reading of your own inventory before committing to a plan, an Operational Architecture Diagnostic is a 30 minute conversation to go through it with you. [Book a conversation](/en/contact).