Bubble to Next.js Cutover Plan (2026)
Mahima Arora
Co-Founder & CEO
If you are reading this, your Bubble app probably did its job. It got you to revenue, or at least to real users. Now you are staring at the same ugly moment every founder hits: scaling on Bubble is getting weird, expensive, and slow to change.
Most migration posts talk like it is a simple rewrite: export data, rebuild UI, ship. That is not how it goes. The hard part is the cutover. The minute you have two systems in flight, you have duplicate writes, broken auth, and angry users.
This post is a battle-tested cutover plan for moving a Bubble product to Next.js in 2026 without doing a six month freeze. It is opinionated. It assumes you want to keep shipping while you migrate.
When a Bubble to Next.js migration is actually worth it (2026)
If you are a founder in the US, UK, Europe, Canada, or Australia, here is the blunt version: you migrate when Bubble is blocking growth, not when Bubble annoys you.
Good reasons:
- Your app needs real backend constraints (multi-tenant, audited data, complex roles) and Bubble logic is turning into spaghetti.
- You are paying for capacity you cannot predict. The bill jumps, but you cannot tie it to one query or one workflow.
- You need performance control. You have a hot page that is slow and you cannot profile it properly.
- You need deeper integrations (Stripe Connect edge cases, vendor webhooks, queues) and Bubble is forcing hacks.
Bad reasons:
- You want to ‘own the code’ but you still do not know what features drive retention.
- You saw a tweet about ‘vibe coding’ and now want to rewrite everything.
If you are doing less than about $10k MRR, I usually push founders to squeeze more out of Bubble first. But if you are B2B with gnarly permissions, the rewrite can be worth it earlier because security mistakes are expensive.
The migration myth: the rewrite is not the risk, the cutover is
Most teams underestimate the cutover because they treat Bubble like ‘just a UI’. It is not. Bubble is your database, your auth, your scheduler, your permission layer, your email triggers, and your file storage. You are replacing a whole platform.
The risk is not that Next.js is hard. The risk is that you end up with two sources of truth and a half-migrated product.
Your goal should be boring: one system writes the truth, the other reads it, until you flip it. That is the core idea behind this plan.
Pick your target architecture before you touch code
In 2026, a sane default stack for ex-Bubble teams looks like this:
- Next.js (App Router) for UI and server actions
- Postgres (Supabase or managed Postgres)
- Auth: Supabase Auth or Clerk (pick one, do not roll your own)
- Payments: Stripe
- Background jobs: a queue (Upstash QStash, BullMQ on Redis, or a hosted worker)
- Files: S3-compatible storage (Supabase Storage, S3, or Cloudflare R2)
If you are US-based and have any compliance pressure (SOC 2, HIPAA-adjacent workflows, finance), you want Postgres with Row Level Security or a clear tenant boundary. Supabase RLS is a solid option when used carefully. It lets you enforce rules in the database, not in random API routes.
One warning: RLS is not magic. You can still shoot yourself in the foot with bad policies. But it is miles better than trusting every client call.
A realistic timeline and cost range (based on what we see)
Here are numbers that match what we see when a Bubble app is real and messy (not a weekend MVP). These ranges assume a small US/UK team or a mixed team with a senior lead.
Scenario A: ‘Thin Bubble’ app (mostly CRUD + Stripe)
- Time: 4 to 7 weeks
- Cost: $20k to $45k
- Why it is cheaper: fewer workflows, fewer edge cases, data model is clean
Scenario B: ‘Typical Bubble SaaS’ (roles, workflows, email, dashboards)
- Time: 8 to 12 weeks
- Cost: $45k to $95k
- Why it stretches: permissions, reporting, exports, background tasks
Scenario C: ‘Bubble as backend’ (marketplace, heavy automations, messy data)
- Time: 12 to 20 weeks
- Cost: $90k to $180k
If those numbers scare you, good. They should. The worst outcome is spending $40k and still being stuck because you did not plan the cutover and data sync.
The cutover plan: build a bridge, not a new island
The plan has five phases. The punchline: you do not flip everything at once. You move writes first, or reads first, depending on the riskiest parts of your product.
Phase 0: Inventory Bubble like it is production code
Before you write Next.js, you list what Bubble is doing today:
- Data types (tables) and fields
- Privacy rules and role checks
- Workflows (especially backend workflows)
- Scheduled events
- External API calls and webhooks
- Stripe, email, file uploads
This takes 1 to 3 days if you are disciplined. If it takes 2 weeks, your Bubble app is already in trouble. That is not a reason to avoid migrating. It is a reason to migrate with extra care.
Phase 1: Stand up the new core (db + auth)
Your first milestone is boring: users can sign in, and you can represent tenants and roles in Postgres.
If you go with Supabase RLS, write policies early. Treat them like tests. If you go with Clerk, do not leave auth checks scattered around. Centralize them.
Budget: 3 to 7 days.
Phase 2: Data migration with a repeatable pipeline
Do not do a one-off CSV export and hope. You want a repeatable script that you can run 10 times.
Typical approach:
- Export from Bubble via API or CSV
- Transform with a script (Node or Python)
- Load into Postgres with id mapping tables
The trick: preserve Bubble IDs in a dedicated column (bubble_id). That single choice makes debugging 10x easier.
Budget: 5 to 12 days, depending on data mess.
Phase 3: Strangler routes (move one user journey at a time)
You do not need to rebuild the whole UI first. Pick one journey that hurts and rebuild it end-to-end.
Good first journeys:
- Login + onboarding
- A core dashboard
- Billing portal
Use a subdomain or path-based routing. Example: app.yoursite.com stays Bubble, but app2.yoursite.com is Next.js during migration. Or /new/* routes to Next.js.
Budget: 2 to 6 weeks, this is most of the work.
Phase 4: Dual-write only if you have to
Dual-write sounds ‘safe’, but it is where migrations go to die. Every bug becomes a data bug. If you can avoid it, avoid it.
Better patterns:
- Make Postgres the source of truth and have Bubble read via API
- Or keep Bubble as truth, and have Next.js read from Bubble until the last moment
If you must dual-write (like for a marketplace where both systems must handle orders), you need an event log. Not vibes. An event log. Even a simple append-only table helps you replay and reconcile.
Phase 5: Cutover day (the checklist)
Cutover is not a single deploy. It is a checklist you run like a pilot:
- Freeze Bubble writes (maintenance mode)
- Run final migration sync
- Turn on Next.js writes
- Verify auth, billing, and 5 to 10 core workflows
- Keep Bubble read-only for 2 to 4 weeks
If you are in the US and have enterprise customers, schedule cutover inside their business hours. Founders love midnight deploys. Enterprise buyers do not.
What usually breaks (and how to stop it)
Auth mismatch
Bubble has its own auth model. When you move to Next.js + Supabase or Clerk, users will hit weird states: signed in on one app, signed out on the other.
Fix: choose one login surface. During migration, route all login traffic to the new system, even if the user ends up back in Bubble for some pages.
Permissions drift
Bubble privacy rules are often ‘soft’. People add exceptions over time. When you rebuild, you will accidentally tighten or loosen access.
Fix: write a permissions matrix. Literally a table: role x action. Then implement it in code and (if using RLS) in SQL policies.
Background workflows
Bubble backend workflows do more than you remember. They send emails. They retry stuff. They update fields quietly.
Fix: export the list of backend workflows and rewrite them as explicit jobs. Use idempotency keys. Treat every job like it can run twice.
Stripe edge cases
If you have Stripe webhooks, you will learn the hard way that events can arrive out of order. Also: retries. Also: duplicate deliveries.
Fix: store webhook event IDs and ignore duplicates. Do not rely on ‘latest state’ updates. Use Stripe’s event id as your idempotency key.
Reporting queries
Bubble hides ugly queries. Postgres does not. Your dashboard filters that felt fine can turn into slow GROUP BY monsters.
Fix: add the right indexes and precompute if needed. I would rather ship a nightly aggregated table than ship a slow dashboard.
How to keep shipping while migrating
If you stop shipping for 10 weeks, you will hate your life. Here is how we avoid the stall:
- Do not rebuild every pixel. Match the UX, not the exact UI.
- Rebuild the money path first (signup, billing, core value).
- Put a senior dev in charge of the data model. If juniors are inventing tables, you will rewrite twice.
- Keep a migration scoreboard: which journeys are on Next.js, which are still Bubble.
- Every Friday, delete one Bubble workflow. Just one. It adds up.
This is also where AI coding tools help. Cursor and Copilot are great for grinding out UI and form plumbing. They are bad at data modeling and security. Use them like power tools, not like a CTO.
A simple decision: keep Bubble read-only or delete it
After cutover, you have a choice.
Option 1: keep Bubble read-only for a month. This is the safe move. It gives you a reference and a rollback path.
Option 2: delete it fast. This is the cheaper move long-term because you stop paying attention to it.
My take: keep it read-only for 2 to 4 weeks, then rip the band-aid off. If you keep Bubble around for 6 months ‘just in case’, you will keep paying the tax.
If you want help
HeyDev has done these rescues for founders who outgrew no-code. If you are in the US or UK and want a fast, low-drama migration plan, reach out. We will tell you if your app is Scenario A, B, or C, and what it will cost.
And if you are not ready to migrate yet, that is fine too. Just do yourself a favor: document your Bubble workflows now. Future you will thank you.
---
Related reading
Mahima Arora
Co-Founder & CEO
Ex-Microsoft engineer and IIT Kanpur alumna. Mahima leads product strategy and AI solutions at HeyDev, bringing deep expertise in building scalable systems from her time at one of the world's largest tech companies.
