bubble → code migration
Move it to code without turning it off.
We build the backend alongside your live Bubble app and move workflows across one at a time. The frontend is swapped last. There is no cutover date, no dark period, and you can stop after any phase with something that still works.
01 · the cost argument
Workload Units are a metered bill with no ceiling.
Bubble prices the work your app does, not the value it produces. A background job that runs every minute costs the same whether you have ten users or ten thousand. That is fine until it is not, and the month it stops being fine is the month you find out.
So do not take our word for it. This is the same calculator that lives on its own page, with the same published pricing config, including the verdict where it tells you to stay where you are.
01 · your app
Five numbers. Nothing else.
250,000 WU and 100 GB included
Monthly billing costs more: $134 against $119
Bubble → Settings → Usage → last 30 days
Monthly actives, not signups
0 if you host files somewhere else
Recurring and API workflow schedules
Typical range is €5,000–€15,000. Change it and watch break-even move.
Nothing is sent anywhere. The calculation runs in your browser against the pricing config published below, last checked 2026-08-06.
02 · the verdict
Your number, both directions.
verdict
Migrating pays for itself in 13 months.
Most of this bill is Workload Unit overage rather than the plan itself, metered per thousand units and growing with usage rather than with revenue. You can switch overages off, but that caps the bill by capping the app.
- bubble · next 12 months
- €9,527
- Growth plan plus 2.65M WU/month of overage, 87% of the bill
- next.js + supabase + vercel
- €588
- Supabase Pro and one Vercel Pro seat, at ~308 GB egress and ~12.3 GB of database
break-even
13 months
Against a €9,500 migration, at €8,939 saved a year.
- You are paying overage. Before migrating, check whether a workload tier or a few dead scheduled workflows would fix it more cheaply.
- 12 scheduled workflows do not change this bill, but they are the most common thing missed in a migration, and the most common cause of silent WU spend.
02 · beyond cost
Cost is the trigger. It is rarely the only reason.
Hiring
You cannot hire a Bubble developer the way you hire a React developer. The pool is small, expensive, and every hire is a bet on one platform staying healthy.
Performance
Page weight and workflow latency have a floor you do not control. When the complaint is “it feels slow”, there is a point past which you cannot optimise your way out.
Compliance
SOC 2, HIPAA and public-sector procurement ask questions about infrastructure, logging and data residency that a no-code tenancy cannot answer on your behalf. Bubble gives you between six hours and twenty days of server logs, depending on plan.
Ownership and lock-in
You own the app. You do not own the runtime, so pricing, plugin availability and uptime are decided by someone else on their schedule. Every month you stay, the data model and the workflows get more platform-shaped and the exit gets more expensive.
Acquirer due diligence
Buyers and investors discount what they cannot audit. A codebase in a repository with tests and a deploy history is worth more than the same product on a platform the acquirer will have to migrate themselves. That discount is usually larger than the migration would have cost.
03 · concretely
What “migrating” actually means
Not a rewrite from a blank page. Every Bubble concept has a code equivalent, and the work is translating them one at a time. Target stack is Next.js and Supabase unless your app argues for something else.
- The Bubble databasePostgres
- Types become tables, fields become columns, option sets become enums. The data moves with a scripted export and a verification pass, so you get a row-count and checksum diff rather than a promise.
- WorkflowsAPI routes + background jobs
- Front-end workflows become client actions against typed API routes. Anything slow or scheduled becomes a background job with retries and a log you can actually read.
- Privacy rulesRow-level security
- Each privacy rule becomes an RLS policy enforced by the database itself, so a bug in the application cannot leak a row. This is the part most export tools skip.
- PluginsReplaced, rebuilt, or dropped
- Most map to a well-known library. A few have no equivalent and have to be rebuilt. One or two turn out to be unused. The audit tells you which is which before you pay for any of it.
- Scheduled workflowsCron + a queue
- Recurring events become cron entries; fan-out work becomes a queue. Both become visible, which is usually the first time anyone can see what they cost.
- Bubble file storageObject storage + signed URLs
- Files move to S3-compatible storage in the EU with signed, expiring URLs. Public-by-default uploads are the most common security finding in an audit.
- The UIRebuilt from your existing design
- Screen for screen, using what you already have. This is deliberately last: it is the part users notice, and it is the safest thing to change once the data and the logic are already correct.
04 · the honest part
What breaks, and what it costs you
Every migration hits these. Anyone quoting a fixed price without opening your editor first is guessing, and the guess is priced to protect them, not you.
Hidden logic in workflows
The behaviour nobody documented, usually inside a nested conditional in a workflow written two years ago by someone who has since left. Finding it is audit work, not migration work.
Undocumented privacy rules
Rules accumulate. Some are load-bearing, some are dead, and no one on your side knows which. Every one has to be read and reproduced as a policy.
Plugins with no code equivalent
A calendar, a signature pad, a niche payment integration. Rebuilding one is a week; there is no honest way to quote it sight-unseen.
Scheduled and recurring workflows
Easy to miss because they are invisible in the editor until you go looking. Missing one means an email that silently stops sending three weeks after cutover.
File storage migration
Volume and permissions, not difficulty. The risk is broken links and public files that should never have been public.
Running both systems at once
For part of the project your data lives in two places. That is a real cost in synchronisation work, and it is the price of never taking the app offline.
Which of these apply to your app, and what each one costs, is what the audit answers.
05 · the method
Incremental, not big-bang.
Competitors sell a rebuild and a switch. This is a controlled replacement, and there is never a Friday night where everything changes.
now
Live Bubble app. Nothing has changed.
100% still on Bubble, 0% on your own code.
phase 1
Postgres, API and auth stood up alongside. Bubble reads from them.
72% still on Bubble, 28% on your own code.
phase 2
Workflows move across one at a time. Both systems live.
34% still on Bubble, 66% on your own code.
phase 3
Frontend rebuilt screen by screen behind the same domain.
8% still on Bubble, 92% on your own code.
cutover
Bubble subscription cancelled. You own the repository.
0% still on Bubble, 100% on your own code.
06 · process
Audit first. Then one phase at a time.
Typical range is four to ten weeks depending on how much app there is. Phases are priced and invoiced separately, so you are never committed further than the phase you are in.
Audit · 1 week
Read access to your editor, a walkthrough, your plan and your Workload Unit usage. Out of it: a feature-parity map, a 12-month cost comparison, performance findings, a risk list, and a fixed quote for everything below.
Migration plan
The phase breakdown, what moves when, what gets rebuilt versus replaced, and where the two systems overlap. Yours to keep whether or not we do the work.
Phase 1 · backend
Postgres schema, row-level security, auth and the API. It runs alongside your live app. Nothing user-facing changes.
Phase 2 · workflows
Workflows move across in dependency order, each verified against the Bubble behaviour before the old one is switched off.
Phase 3 · frontend
Screens rebuilt from your existing design, released behind the same domain. Users see the app they already know.
Cutover
Bubble subscription cancelled, DNS finalised, repository and infrastructure handed over with a runbook. You own all of it.
07 · published, not hidden
What it costs
Ranges are published because hiding them wastes both our time. The audit produces the fixed number; everything below is the bracket it will land in.
- Audit
- €500–750
- Fixed price, one week. Credited in full against a migration if one follows.
- Migration · small app
- €5,000–8,000
- Up to around 15 pages, straightforward workflows, no exotic plugins.
- Migration · mid-size
- €8,000–12,000
- Multiple user roles, Stripe or subscriptions, real background work.
- Migration · complex
- €12,000–15,000
- Heavy plugin surface, integrations, or compliance requirements.
- Per-phase option
- by phase
- Larger jobs are invoiced phase by phase instead of 50/50. Stop after any phase.
Terms: 50% on start, 50% on delivery, or phase by phase for larger jobs. Prices exclude VAT where applicable. There is no retainer attached to a migration and no obligation to keep us afterwards; the handover includes a runbook written for a developer who has never seen the project.
08 · faq
The questions everyone asks
Will my app go down?
No. There is no single cutover date and no dark period, and if a phase goes badly the app is still running on Bubble.
Do I lose data?
No. Data is exported, loaded, and verified with row counts and checksums before anything is switched over, and Bubble keeps running until it matches. You also keep your Bubble app until you choose to cancel it.
Can I keep some things on Bubble?
Yes, and sometimes you should. An internal admin panel that nobody complains about is a bad use of migration budget. The audit says which parts are worth moving and which are not.
What happens to my Bubble subscription?
It stays active through the whole project. That is what makes the method safe. You cancel it at cutover. Budget for the overlap; it is usually one to three months.
Who owns the code?
You do, from the first commit. The repository is in your organisation, the infrastructure is in your accounts, and the handover includes a runbook. There is no hosting lock-in and no licence to renew.
What if I want to maintain it myself afterwards?
That is the expected outcome. The stack is chosen partly because you can hire for it. If you would rather not, maintenance is a separate retainer, but it is never a condition of the migration.
How do I know it is worth it?
Run the calculator on this page with your own numbers. If the break-even is longer than a couple of years, do not migrate. We will tell you the same thing on a call, for free, before you pay for anything.
Start with the audit.
One week, €500–750, credited against the migration. You get a feature-parity map, a 12-month cost comparison, a risk list and a fixed quote, and no obligation to use any of it here.