Moving a Bubble app to code: should you, how, and what it costs

Should you migrate?

Bubble is a reasonable place to validate an idea and a reasonable place to run a business for years. Migration makes sense when one specific constraint now costs more than a rebuild would.

Signs it is time to move:

• Platform cost climbs with usage and you cannot predict the bill.
• The app needs heavy background processing, real-time behaviour at scale, native mobile, or integrations that depend on plugins.
• You, a future hire, or an acquirer needs to own a standard codebase.
• Changes are slow and fragile because the logic lives in a visual editor with hundreds of workflows.

Signs to stay on Bubble and fix the app first:

• The product is still finding its shape and the spec changes every week.
• Cost is small and stable compared with revenue.
• The slowness comes from the data model or unindexed searches. Those carry over to code unchanged.

How the migration is sequenced

1. Audit. List data types, workflows, reusable elements, plugins, external API calls and scheduled jobs. Count what is actually used. The open source bubble_ex library can export a Bubble app's data model as DBML, Postgres SQL or Ecto schemas, which gives the schema review a concrete starting point.
2. Design the target data model. Bubble lets fields and relationships stay loose. Postgres will not. This is where most of the real work sits.
3. Pick the first slice. Choose a self-contained workflow with clear inputs and a small blast radius, not the most visible page. Our guide to choosing the first slice covers the criteria.
4. Run both systems. Bubble stays the source of truth while the replacement is built, tested and given real traffic. Move data in repeatable batches with reconciliation counts.
5. Cut over slice by slice. Retire the Bubble version only after the new one has run cleanly for a full billing or usage cycle.

Cost and timeline

There is no honest number without an audit. What moves the estimate: how many data types and workflows are actually used, how many plugins wrap third-party APIs, the auth migration, data volume and cleanliness, how many integrations need a parallel run, and whether you rebuild or refactor.

Be wary of any price quoted before someone has read your app. Ask for a fixed price after a paid discovery step, and check what the scope includes: data import, auth, parallel running and cutover support are the usual gaps.

Getting your data out

• Read records out through the Bubble Data API, one data type at a time. Confirm the export options and rate limits for your plan before you plan around a large table.
• Keep Bubble's unique ID as a column in the new schema. You need it to reconcile counts and to dual-write during cutover.
• Relationships in Bubble are references and lists, so export each type with its IDs and join on those.
• Assume you will not get password hashes out of Bubble. Plan for a password reset or a passwordless first login, and tell users before the switch.
• Bubble-hosted files may need to be downloaded and re-hosted, which changes their URLs. Plan an asset map.

What breaks

• Privacy rules become row-level security or explicit authorization in code. Anything that relied on Bubble's implicit checks needs a test.
• Backend and scheduled workflows become a job queue with retries and idempotency. Double-sent emails are the classic failure.
• Plugins each wrapped an API. Call the API directly, and find out what the plugin actually did before you remove it.
• Searches become indexed queries. Slow ones only show up with real data volume.
• Responsive layouts and conditional styling get rebuilt, not converted. Budget a visual comparison pass on desktop and mobile.
• URLs and SEO need a redirect map from every indexed Bubble URL.
• Sessions sign users out unless you bridge auth between the two systems.

What we have built, and what it does not do

bubble_ex is an open source Elixir library. It reads a Bubble app and produces its structure: data model exports (DBML, Postgres and SQLite SQL, Ecto, Zod, Xano, Convex), a check for exposed endpoints and secrets, and tooling for Bubble application logs. Use it only on apps you own or are authorized to test.

Rubble is an experimental runtime built on that work. It runs a small imported slice, a task list with add, done and pagination. It is not a general migration tool, and visual parity with Bubble is not established. If you want to know what your app would take, start with the assessment.

Read the migration series

Frequently asked