How to migrate from Bubble to code (2026 guide)

Start with the honest question. If your app works, your users are happy and the bill is fine, staying on Bubble is a perfectly good choice — and Bubble’s Agent 2 and the Bubble MCP (October 2026) make building inside Bubble faster than before. A migration costs time and money and carries risk; it should solve a problem you actually have.

The reasons we hear most often for leaving are concrete ones:

• Ownership. Bubble doesn’t support code exports or self-hosting. Your app only runs on Bubble, on Bubble’s plans.
• Cost you can predict. Bubble charges a plan per app plus workload units for what the live app does, and since October 2026 AI credits for the Agent. See what the October 2026 changes mean.
• People and tools. A standard codebase can be worked on by any developer and by AI coding tools such as Claude Code, Codex or Cursor.
• Control. Hosting region, performance work, SEO, compliance requirements, a database you can query directly.

Experienced Bubble developers also make a fair counterpoint: some apps are slow or hard to change because of how they were built, not because of Bubble, and moving them unchanged moves the problems with them (a good forum thread on this). A migration is a chance to fix what needs fixing — but it doesn’t fix anything on its own.

Before choosing a route, know what Bubble actually gives you. There are four ways to get things out:

Two things never come out: runnable code and password hashes. Everything else — design, logic, data, files — can be moved, which is why the export file matters so much: it’s the most complete description of your app that exists. More on its contents in Can you export code from Bubble?

1. Rebuild it by hand (yourself, a freelancer or an agency)

A developer or team uses your Bubble app as the specification and writes a new app, usually on a stack like Next.js or React with a Postgres database. This gives you the most freedom to redesign, and the result is whatever the team builds. It’s also the slowest and most expensive route. Agencies publish rough ranges — for example, one Bubble migration agency estimates $8,000–$15,000 and 4–6 weeks for a simple tool, up to $35,000–$60,000 and 14–20 weeks for a marketplace — and your own quote will depend on the size of the app and how much changes.

2. Rebuild it with AI coding tools

Tools like Claude Code, Cursor or Lovable can produce pages, API routes and tables quickly. They work best when someone who understands the original app steers them closely. Handing an AI the whole export and asking for “the same app” tends to produce something that looks right and behaves differently: workflows with conditions, privacy rules and edge cases are exactly where guesses go wrong, and nothing tells you which parts were guessed.

3. Convert the export automatically

The export describes every element, style, workflow and data type precisely, so it can be compiled rather than reinterpreted. That’s what deBub does: it reads the .bubble file and writes a Next.js + TypeScript + Supabase project — the same pages, workflows, data model and privacy rules — and lists anything it couldn’t translate one-to-one in a report, marked in the code. You review it in a hosted preview before you go live.

It isn’t magic either. Plugins without a converter get a placeholder of the right size (see which Bubble plugins convert), scheduled backend workflows need a scheduler you choose, and privacy rules that can’t be translated exactly are locked down to the safe side and flagged. The difference is that you start from a working app with a known list of gaps, not from an empty folder.

You can also combine them: convert first, then have a developer or an AI assistant work on the parts you want to change. Since the result is ordinary code, nothing ties you to the tool that produced it.

Your data doesn’t travel in the export; it moves through the Data API. The work is the same whichever route you pick for the code:

1. Map types to tables. Each Bubble data type becomes a table and each field a column with a real type (text, number, date, yes/no → boolean). References to other things become foreign keys; lists become arrays or join tables; option sets become lookup tables. The full mapping.
2. Turn on the Data API in your Bubble app settings and tick each data type you want to copy, then create an API token. The token gives admin read access, so keep it private and delete it once you’re done.
3. Copy users first, then everything else. Things refer to users (Created By, owner fields), so users have to exist before the records that point at them. References between other types are easiest in a second pass, once every row exists.
4. Keep Bubble’s ids. Store each record’s Bubble unique id next to its new id. It makes a repeat copy update rows instead of duplicating them, and it lets you trace any row back to Bubble.
5. Plan a final sync. People keep using the Bubble app while you build. A last copy of everything changed since the previous run (Bubble’s Modified Date makes this possible) right before you switch keeps you from losing anything.

Files — images and uploads — live on Bubble’s file storage and appear in your data as URLs. Download them and re-upload them to your own storage during the copy, and rewrite the URLs. Do this before you cancel your Bubble plan, not after.

Bubble stores passwords separately from your data and doesn’t hand them out — not in CSV exports, not through the Data API (as Bubble staff have explained on the forum). So every migration has to answer one question: how do existing users sign in on the new app?

• A “choose your password” email (recommended). Create each user in the new auth system without a password and send them a secure link to set one. It’s one email, it’s honest, and “Forgot password” keeps working for anyone who misses it.
• Passwordless sign-in. Magic links or one-time codes sidestep the question entirely, if that suits your users.
• A temporary bridge. Some teams check credentials against the old Bubble app (through an API workflow) on first sign-in and save the new password then. It avoids the email, but keeps Bubble in your sign-in path, adds a piece of code that handles raw passwords, and has to be removed later. We don’t recommend it.

Social sign-in (Google, Facebook…) moves more easily: set up the same provider in the new auth system and users signing in with the same email address land on their account. You’ll need your own OAuth client for the provider.

Also move the emails your app sends about accounts — confirmation, password reset, magic links — to a sending service on your own domain, and set up SPF and DKIM so they don’t land in spam.

Bubble’s privacy rules decide who can see and change which records. In a Supabase/Postgres app the equivalent is row-level security (RLS): policies on each table that the database enforces for every request. Two things matter during a migration:

• Translate every rule deliberately, and turn RLS on for every table. A table without RLS in Supabase is readable with the public key that ships in your front end.
• Field-level rules need extra care. RLS works on rows; Bubble rules that hide individual fields need column privileges, a view or a separate table.

Test the result as an anonymous visitor, as a normal user and as an admin before going live. Owning the code also means owning its security: secrets belong in environment variables, never in the code, and the service-role key never goes near the browser.

Page workflows become event handlers in the page’s code; actions that change data run on the server, where you can check who’s allowed to do what. Backend (API) workflows become server functions — and if other systems call them, keep the same URL so you don’t have to change those systems on cutover day.

Recurring events, database triggers and scheduled workflows are the parts Bubble runs for you behind the scenes. In code you pick the tool: a cron job (Vercel Cron, pg_cron) for recurring work, a database webhook for triggers, a queue or pg_cron for “schedule this for later”. Make a list of every one before you start; they’re easy to forget because nothing on screen shows them.

Plugins need a replacement each: usually a well-known npm package or SDK (Stripe, Chart.js, Quill…), sometimes a small component. API Connector calls become server-side requests with the keys in environment variables. Our plugins hub lists what each common plugin becomes in Next.js.

Most migration problems show up on the day you switch, not while you build. Work through this before you point your domain at the new app:

• A staging copy of the new database, set up early, so schema changes are tested before they reach production.
• A full dry run: copy all data into staging, click through every page as each kind of user, compare counts with Bubble.
• Privacy rules / RLS tested as anonymous, normal and admin users.
• All secrets in environment variables on your host; the .bubble export and any API tokens kept private.
• Auth settings pointed at the new domain: site URL, redirect URLs, OAuth clients, email templates.
• Email sending from your own domain with SPF and DKIM.
• Webhooks re-pointed (Stripe, Zapier, anything that called Bubble) — or the old URLs kept working.
• Recurring and scheduled jobs running on the new side, and switched off on the Bubble side at the same moment.
• Files re-hosted and their URLs rewritten.
• Old URLs redirected to new ones, so links and search rankings survive.
• A short freeze (or read-only mode) on Bubble, then the final data sync, then the DNS switch.
• The “choose your password” email sent once the new app is live.
• Bubble kept on its plan, untouched, for a few weeks as a way back.
• Error monitoring on the new app for the first days.

For a hand-built rebuild, think in weeks to months, depending on the number of pages and workflows and how much you change on the way (see the agency estimates above). Data, users and files take days of work on their own if you script them yourself.

With an automated conversion, generating and build-checking the code usually takes well under an hour; your time goes into reviewing the preview, finishing the items in the report and the go-live steps. deBub’s free scan reads your export and shows what converts automatically and a fixed price before you pay anything.