How to migrate from Bubble to custom code without losing users or revenue

When have you outgrown Bubble?

You have outgrown Bubble when the platform, not your team, is setting the limits on speed, cost or what the product can do. That point arrives later than critics claim and earlier than Bubble fans admit.

The signals worth acting on:

• Workload costs climb faster than revenue. Bubble prices on workload units, which aggregate the server resources your app uses. At the time of writing, plans include 50K units a month on Free, 175K on Starter, 250K on Growth and 500K on Team, with more available to buy. If heavy searches or scheduled workflows push you into regular top ups, model the cost at three times your current usage.
• Performance for Australian users. Bubble’s servers are hosted on AWS and every app sits behind Cloudflare’s CDN, but database operations and workflows still run on Bubble’s servers. If your users are mostly in Australia and pages feel slow, measure before assuming the platform is the cause.
• Enterprise buyers ask questions you cannot answer. Data residency, penetration test evidence, single sign on, audit logs and source code escrow come up quickly when you sell to larger Australian organisations.
• You need things the platform does poorly. Complex permissions, heavy background processing, real offline mobile use or deep integrations through custom code.
• Investors or acquirers want to own the code. On Bubble, you own your data and design, but there is no codebase.

If none of these apply, staying on Bubble is a legitimate choice. Our guide to low code vs custom development covers that decision; this guide assumes you have made it.

What can you take out of Bubble, and what can’t you?

You can take your data and a description of your logic; you cannot take a running codebase. Bubble’s FAQ says apps run on its platform so “there’s no traditional codebase to export”, and that it can provide a raw export of your application logic as a JSON file to help a migration.

Asset	Can you export it?	How
Database records	Yes	Data tab export to CSV, JSON or NDJSON, one data type at a time; or the Data API
Uploaded files and images	Yes, with work	File URLs are in the data; download them with a script
App logic	Partly	Raw JSON export from Bubble on request; screenshots and notes of every workflow
Page designs	No, as code	Screenshots and a design file rebuilt from them
Password hashes	No	Hidden even from the developer
Plugins	No	Identify what each one does and find a library or service to replace it
Integrations (Stripe, email, APIs)	Configuration only	Note every API Connector call, key and webhook

Two practical warnings from Bubble’s own manual. Exports run on the same scheduler as API workflows, so a busy app can delay them. And date interval fields export as descriptive text, such as “2 days”, even though they are stored in milliseconds, so check every field type in a trial export.

How do you document the app before anyone codes?

Write the specification from the Bubble editor itself, because the app is the only accurate record of what it does. This step is cheap compared with discovering a missed rule after launch.

Work through the editor in this order:

1. Data types and fields, including option sets. Note which fields are lists, which link to other types, and which are computed in workflows.
2. Privacy rules for each data type. These are your permission model, and they are the part most often lost in a rebuild.
3. Backend workflows and scheduled events: what triggers them, what they change, and how often they run.
4. Page workflows, grouped by user action (“user submits booking”) rather than by page.
5. API Connector calls and plugins, with what each one is for.
6. Emails and notifications, with their templates and triggers.
7. User roles and what each can see and do.

The output is a feature list with acceptance criteria. It also tells you what to leave behind: most Bubble apps carry features and workflows nobody uses.

Which stack should replace Bubble?

Choose a stack your future team can hire for in Australia and that fits how users reach the product. For most Bubble migrations that means a TypeScript web framework, a relational database and a managed hosting platform.

A common target is React or Next.js on the front end, Node.js or Python on the back end, and PostgreSQL as the database, hosted in an Australian cloud region if your customers need onshore data. If you also need native mobile apps, Flutter or React Native share code across iOS and Android. Bubble’s data model of types and linked fields maps cleanly onto relational tables, which makes PostgreSQL a natural fit.

Resist the urge to redesign everything at once. Rebuild the product users already pay for, then improve it.

How do you move users without forcing password resets?

Because Bubble stores passwords as salted one way hashes that even the developer cannot see, you cannot copy them to the new system. You have three practical options.

Option	How it works	Trade off
One time set password email	Create every account in the new system, then email each user a secure link to set a password	Simple and reliable; some users won’t act on the email
Social or single sign on first	If users already sign in with Google or Microsoft, match them by verified email	No password needed; only covers users who used social sign in
Staged sign in	During the overlap, if your Bubble setup can support it, check a user’s credentials once against the Bubble app, then store a new hash in the new system	Fewer emails; more engineering, depends on the old app, and must be security tested carefully

Whichever you choose, migrate a pilot group first and watch support tickets. Tell users before the switch, and keep the old sign in page live with a clear message for a few weeks.

How do you run both apps and cut over?

Run the new app alongside Bubble, move users in groups, and keep a way back until the new app has handled a full billing cycle. The goal is that revenue never depends on a single risky weekend.

1. Freeze new features in Bubble once the rebuild starts, except urgent fixes.
2. Build a repeatable migration script from the Data API or exports, and run it many times against test environments.
3. Migrate internal users, then a pilot group of customers.
4. For the final cutover, put Bubble into a short read only window, run the final data sync, switch the domain, and verify.
5. Move subscriptions. If you use Stripe, customer and subscription records live in Stripe, so the new app connects to the same account rather than recreating them.
6. Keep the Bubble app available read only for a month for reference, then export a final archive and downgrade the plan.

What does it cost compared with staying?

Compare a one off rebuild against three years of platform cost, workaround effort and lost deals, not against this month’s Bubble invoice. At the time of writing, Bubble’s paid plans start at $32 (USD) a month for web, billed annually, and workload drives cost above that.

The rebuild cost depends on the number of workflows, roles and integrations. Typical Australian ranges for this size of product are in our MVP development cost guide and SaaS development cost guide. A rebuild also creates ongoing costs you didn’t have before: hosting, monitoring, security updates and maintenance.

How do you choose a team for the rebuild?

Choose a team that will read your Bubble app before quoting, and that hands over the code and the documentation. A quote based only on screenshots will miss the privacy rules and backend workflows.

Ask who owns the code and when it is assigned to you, how users will be migrated, what the rollback plan is, and who maintains the app after launch. Our guide to rewrite vs refactor explains why staged rebuilds beat big bang rewrites, and the same thinking applies here. If your app came from an AI builder rather than Bubble, see making an AI built app production ready.

How AWLabs approaches Bubble migrations

We start with a Development Consult, then a paid Discovery Audit, credited in full against the build, in which we read the Bubble editor directly and produce the feature list, data map and user migration plan. The rebuild is priced as a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete. Senior engineers lead every build, you get updates every Tuesday and Friday, and the code is assigned to you as it is paid for. If staying on Bubble is the better answer, we will say so. See startup MVP development and SaaS development.