Migrate a Bubble app to custom code when the product needs something the platform can't give it, such as control over costs, performance, data location or the code itself, not simply because it was built without code. Bubble exports your data but not your app as code, so a migration is a rebuild. Plan it in stages.

Picture a founder whose scheduling marketplace has run on Bubble for two years. It found its first paying customers, raised a small round and now has a waiting list of enterprise buyers. The enterprise security questionnaires ask where the code lives and who can audit it. The monthly platform bill has started to move in ways nobody on the team can predict. A developer friend says "just export it to React". There is no such button.

Can you export a Bubble app as code?

No. Bubble's own manual is direct about it: "Bubble apps can only be run on the Bubble platform; there's no way of exporting your application as code." Moving off Bubble means rebuilding the application logic in a new codebase.

What you do own is set out on Bubble's Application and data ownership page: you have "ownership over your data, encompassing both your app's design and any data uploaded by your users", while "Bubble retains ownership of the underlying code that powers your app." The same page notes that if Bubble were ever discontinued, its source code would be released under an open-source license so apps could run on a self-hosted Bubble server.

In practice, three things carry over from Bubble to a new stack:

• Data: the records in your database, exported as files or read through the API.

• Design: the screens, layouts and user journeys, which become the specification for the new front end.

• Business rules: the logic in your workflows, which has to be read and written down by hand, because nothing translates it automatically.

When should you migrate a Bubble app to code?

Migrate when a specific business need can't be met on the platform, and the cost of meeting it elsewhere is lower than the cost of not meeting it. "No-code doesn't scale" on its own is not a reason. Plenty of products run on Bubble for years.

These are the signals that usually justify a move:

1. Buyers or investors need to own and audit the code. Security reviews, due diligence or a sale may require a codebase the company controls.

2. Costs no longer track the business. Bubble bills by workload, which its pricing FAQ defines as "a measure of the work that Bubble does in order to power your application", covering "database operations, workflows, and web requests". If you can't explain or control why that number moves, it is worth measuring which features drive it before deciding anything.

3. Performance limits hit the core journey. Heavy searches, large lists or complex calculations that slow the screens users depend on.

4. The product needs things the platform handles awkwardly, such as complex real-time features, custom data processing or deep integration with your own infrastructure.

5. Hiring and handover. The team you want to hire works in code, and every new Bubble specialist is harder to find than the last.

Some reasons are weaker than they look. Mobile is one: Bubble now supports native mobile apps published to the Apple App Store and Google Play, so needing an app in the stores is no longer a reason to leave on its own. If only one of the signals above applies, check whether it can be solved inside Bubble or by moving one part out, before committing to a full rebuild.

What do you need to get out of Bubble before you start?

Get a full copy of your data, a written record of your workflows and privacy rules, and a list of every outside service the app talks to. Do this before the rebuild starts, because these are the specification.

Data

Bubble's database editor exports data as CSV, JSON or Newline-Delimited JSON (NDJSON), and Bubble emails a download link when the export is ready. The manual on exporting data warns that exports run "on the same scheduler that handles API workflows", so a busy app may see delays. For repeatable or larger exports, the Data API lets other systems "search for, read, create, modify and delete data" through a RESTful interface. It is disabled by default and is switched on per data type under Settings, API. Access through it is "controlled by the privacy rules applied to that particular data type", so check that your export can actually see every record.

User passwords

Passwords do not come with you. Bubble's user accounts guide explains that passwords are hashed and salted, and "not even Bubble can" see the originals. Plan how users will sign in on the new system: a password reset on first login, a sign-in link sent by email, or a single sign-on provider.

Workflows, rules and integrations

• Every workflow, written as plain steps: trigger, conditions, actions.

• Every privacy rule, as a sentence: who can see or change which records.

• Every plugin and API connection, with the account it runs under.

• Every scheduled or backend workflow, with how often it runs.

• Uploaded files, and where the records that point to them live.

How do you migrate from Bubble without stopping the business?

Rebuild in stages while the Bubble app keeps running, and move users over one part at a time. A single cut-over date for the whole product puts every risk on one day.

Martin Fowler calls this approach the Strangler Fig Application: new parts are built next to the old system and take over its behaviour piece by piece. For a Bubble app, a workable order looks like this:

1. Design the new data model first. Bubble's data types are a starting point, not a schema to copy. Fix the relationships, ownership and naming you would get wrong today.

2. Stand up the new back end and sync data into it. Use exports or the Data API to keep the new database in step with Bubble while both run.

3. Move one journey at a time. Start with a part that has clear edges, such as an admin panel or a reporting screen, then the core user journeys. Bubble keeps serving everything not yet moved.

4. Run old and new side by side. For each moved journey, compare results on real cases before switching users over.

5. Switch sign-in and the final data last. Move authentication when most journeys already run on the new stack, do a last data sync, and keep Bubble read-only for a period afterwards.

Some teams choose a full rebuild with one switch-over instead, usually when the app is small or the data model needs to change completely. That can work, but write down what the old app does before turning it off. Our post on fixing or rebuilding someone else's app covers how to make that call.

What breaks most often in a Bubble migration?

The usual failures are missing business rules, data that doesn't fit the new model, and users locked out on switch-over day. All three come from moving faster than the specification.

• Hidden logic. Conditions on buttons, rules inside privacy settings and backend workflows that run on a schedule are easy to miss. Each one is a business rule that the new app will quietly drop.

• Data shape. Lists stored inside records, option sets and text fields used for several purposes need cleaning before they fit a relational database.

• Sign-in. Without passwords, users need a clear, tested way back in. Send the reset or sign-in link before launch day, not on it.

• Missing production basics. A new codebase needs what the platform used to handle: hosting, backups, monitoring, error alerts and access control. Our list of what breaks when an app gets real users applies here too.

How we approach it at Vizio AI

We start by asking whether the app needs to leave Bubble at all. If one feature or one cost driver is the problem, moving that part out is often enough, and the rest of the product stays where it works.

When a move is the right call, we treat the Bubble app as the specification. We export the data, write down every workflow and privacy rule in plain language, and agree with the founder on the new data model before writing code. Then we rebuild in stages, keep the Bubble app running until each journey is proven on the new stack, and hand over a codebase, accounts and documentation that the founder's own team can run.

This work sits in our Venture Studio. If your no-code MVP has stalled or outgrown its platform, Finish Your Build is where to start.

Sources

• Bubble Manual, Application and data ownership: https://manual.bubble.io/account-and-marketplace/application-and-data-ownership

• Bubble Manual, Exporting data: https://manual.bubble.io/help-guides/data/the-database/export-import-data/exporting-data

• Bubble Manual, The Data API: https://manual.bubble.io/core-resources/api/the-bubble-api/the-data-api

• Bubble Manual, User accounts: https://manual.bubble.io/help-guides/data/user-accounts

• Bubble Manual, FAQ: Pricing and Workload: https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq

• Bubble Manual, Native mobile app: https://manual.bubble.io/help-guides/publishing-your-app/native-mobile-app

• Martin Fowler, Strangler Fig Application: https://martinfowler.com/bliki/StranglerFigApplication.html

• Vizio AI, Finish Your Build: https://www.vizio.ai/finish-your-build