BYD TechThe short answer
Move off Bubble when its limits hold the business back more than a rebuild would: performance or workload you cannot tune away, logic that has become too risky to change, or customers and investors asking security questions you cannot answer. Bubble lets you export your data and reach it through its Data API, but your app’s logic cannot be exported as code, so a migration means rebuilding the logic and moving the data. Most teams do it piece by piece, with Bubble and the new app running side by side until the switch.
Key points
- Bubble lets you take your data, not your app: the logic has to be rebuilt.
- Try to fix performance in Bubble first. Some slow apps are slow because of how they were built.
- Moving piece by piece is usually safer than switching everything at once.
- Plan as if passwords will not carry over: Bubble keeps only a one-way hash that no one can read, so decide how users will sign in to the new app.
- Run the old and new apps side by side and compare results before you switch.
Signs it is time to move
- Performance you cannot fix. Pages and workflows stay slow after you have simplified searches and moved heavy work to the backend.
- Workload you cannot predict. Bubble measures the server resources an app uses in workload units, and page loads, searches and workflows all count toward it. When growth makes that number impossible to forecast or reduce, it becomes a business problem.
- Hard limits. Bubble documents fixed boundaries, such as a timeout on long-running workflows and a cap on how many items a list field can hold. Some can be raised on a higher plan; others cannot.
- Logic that is too risky to change. The workflows have grown so tangled that every change breaks something else, and nobody can test them.
- Security and data questions. Customers or investors ask where data is stored, who can reach it and how it is protected, and the honest answers depend on a platform you do not control.
- Hiring. You want engineers to own the product, and the people you want to hire work in code.
Signs it is not time yet
- You are still looking for product-market fit. Changing the product quickly matters more than the platform under it; see What is product-market fit?.
- The slowness comes from how the app was built: searches without constraints, long lists stored on records, heavy work done in the page. Those can be fixed in Bubble first.
- The problem is one feature. It may be easier to build that feature as a separate service and keep the rest in Bubble.
- Nobody is ready to own the code. A coded app needs someone to maintain it, keep it secure and deploy it, or it collects technical debt quickly.
No-code is a sound choice for many products for a long time. Low-code vs no-code vs custom code covers where each one fits.
What you can and cannot take out of Bubble
Bubble’s manual is clear about ownership: you own your app’s design and the data your users upload, while Bubble keeps the underlying code that runs the app. Bubble apps only run on Bubble, and there is no way to export one as code. That split is the whole migration in one sentence: the data moves, the logic is rebuilt.
| Part of the app | Can you take it? | How |
|---|---|---|
| Database records | Yes | Export from the Data tab as CSV, JSON or NDJSON, or read them with a script through the Data API |
| Workflows, conditions and privacy rules | No | Rebuild them in code, using the Bubble editor as the specification |
| Design | Partly | You own it, and Bubble says it can help export it, but the pages are rebuilt in code |
| User passwords | Not readable | They are stored as a salted, one-way hash that is invisible even to the app’s developer, so plan a new way for users to sign in |
| Outside integrations | The connections, not the setup | The services stay the same; the calls made through the API Connector are rebuilt in code |
Two export details are worth knowing. Exports share a queue with scheduled backend work, so they can wait when the app is busy. And date interval fields export as descriptive text rather than the number stored in the database, so convert them before loading.
Three ways to migrate
| Approach | How it works | Fits when | Watch out for |
|---|---|---|---|
| Full rebuild | Build the whole app in code, move the data and switch everyone over at once | The app is small, or its logic needs a redesign anyway | The Bubble app keeps changing while you rebuild, and everything goes live together |
| Piece by piece | Move one part at a time to code, sharing data with Bubble through its Data API and backend workflows until nothing is left in Bubble | The app has active users and cannot pause | For a while data lives in two places, and both have to stay in step |
| Keep Bubble for admin | Rebuild the customer-facing app in code and keep internal screens in Bubble, calling the new app through the API Connector | The admin screens work well and only staff use them | Two systems to maintain, and Bubble still has to reach the data |
Piece by piece is the strangler fig approach applied to Bubble. Rewrite or refactor? explains why it is usually less risky than replacing everything at once.
Bubble provides the connections that approach needs. The Data API, which is off until you enable it and choose each data type to expose, lets an outside system read, create, edit and delete records, within your privacy rules. Backend workflows can be exposed through the Workflow API, so the new code can trigger logic that still lives in Bubble. The API Connector works in the other direction, for calls from Bubble to the new app. Expose only the data types and workflows the migration needs, and require authentication on each one.
Moving the data and user accounts
- Map every Bubble data type to a table in the new database, including list fields, option sets and the links between records.
- Keep each record’s Bubble unique ID in a column of the new database, so records can be matched and the import can be rerun safely.
- Export the data, or read it through the Data API with a script, then transform it and load it into the new database. Do a full trial run first.
- Copy uploaded files to storage you control and rewrite the links that point to them.
- Check record counts for every type, spot-check a sample by hand, and follow a few real accounts through the new app end to end.
- Plan sign-in. Because Bubble keeps only a salted, one-way hash of each password that not even Bubble can read, plan as if passwords cannot be copied across. Common options are asking users to set a new password on their first visit, or sending a sign-in link by email.
The switch is also a good moment to offer passkeys, which need no password at all; see What are passkeys?. Whatever you choose, tell users before the switch what will change for them, in a short message.
Running both and switching over
- Decide which system is the source of truth for each type of data at every stage, and write it down. Two systems writing the same records is where data goes wrong.
- Run the new app beside Bubble with real data, first for your own team, then for a small group of users.
- Compare results: the same inputs should produce the same records, emails and charges in both.
- Plan the switch: stop changes in Bubble, run the final data sync, point the domain at the new app and watch errors closely.
- Keep the Bubble app available, read-only, until you are sure nothing is missing, then export a final copy of the data before closing it down.
If you move a Bubble app to code with BYD Tech, the new code lives in your GitHub from the first day and the cloud accounts are opened in your name. Web app development describes how we approach the build.
Sources
Checked when this guide was written.
