Bubble migration service

Migrate Your Bubble App to Custom Code

Bubble apps can’t be exported as code, so moving off Bubble means rebuilding the app, with your live Bubble app as the specification. We assess your app first, then optimize it, move it in phases, or rebuild it in Next.js and Supabase while your users keep working.

Bubble was the right tool to reach this stage. When the trade-offs change, the same team that understands your app moves it to a foundation you own.

  • Certified Bubble developers
  • We moved our own site off Bubble in 2026
  • You own the code, data and accounts

Last updated October 15, 2026 · By the MindForApps team

At a glance

Can a Bubble app be exported as code?
No. Bubble apps only run on Bubble, so moving means rebuilding.
Does the data come with you?
Yes. Records export as CSV or through the Data API; files move too.
Do users keep their passwords?
No. Plan a reset or keep sign-in through Google or another SSO.
Does the app go offline?
Only briefly. Bubble stays live until a planned, rehearsed cutover.

Signs it’s time to look beyond Bubble

None of these on its own means you should rebuild. Two or three together usually justify an assessment.

  • Workload unit costs grow faster than revenue
  • Public pages need to rank and be read by AI assistants
  • Large searches and reports are your bottleneck
  • Investors, buyers or clients ask who owns the source code
  • You need Git, code review and automated tests
  • Compliance or hosting rules Bubble can’t meet
  • Mobile plans go beyond what Bubble’s builder covers
  • Every change depends on one Bubble specialist

The main problems with Bubble apps, and how code solves them

Each answer below says when Bubble is still the better choice. We’d rather you stay on Bubble than migrate for the wrong reason.

Why are Bubble apps slow to load?

Every Bubble page loads Bubble’s shared runtime before it shows your content. Forum tests from November 2024 reported a Lighthouse mobile score of 28 for a Bubble blog page, and about 2.5 seconds and 2 MB transferred for an otherwise blank Bubble page. These are individual tests, not a benchmark. A Bubble app can be optimized, but the runtime sets a floor you don’t control.

How code solves it

Next.js renders pages on the server or at build time, sends only the JavaScript each page needs, and gives you control over images, fonts and caching. It doesn’t guarantee good Core Web Vitals; it gives you the levers to get there.

When Bubble is still fine

Internal tools and dashboards behind a login, where shipping features matters more than the first page load.

Sources: Bubble forum: blog page performance test (November 2024); Bubble forum: page load speed test (November 2024); Google Search Central: Core Web Vitals

Can ChatGPT, Claude and Perplexity read Bubble apps?

Often not. Bubble builds most of the page in the browser with JavaScript. The main AI crawlers (GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot) download JavaScript files but did not run them in Vercel and MERJ’s December 2024 analysis. They read the HTML that arrives before JavaScript runs, and on a typical Bubble app that HTML is almost empty. Google and Bing are different: Googlebot and Bingbot do render JavaScript, so Google can index Bubble pages, although rendering is queued and Google still recommends server-side rendering for important content.

Our test: what an AI crawler can read

PageWhat it isReadable words
yogaease.bubbleapps.ioPublic Bubble demo app1
top-realtor.bubbleapps.io/demoPublic Bubble demo app2
1dashboard-template.bubbleapps.io/demoPublic Bubble demo app1
bubble.ioBubble’s own marketing site3,764
www.mindforapps.comThis site, built with Next.js2,319

Tested October 15, 2026. We requested each page once with the GPTBot user agent, without running JavaScript, and counted the words outside script and style tags. The three Bubble apps included 33–41 script tags each. Three apps is a small sample, and results vary by app; Bubble’s own marketing site serves its text in HTML.

How code solves it

Server-rendered pages put your full text into the first HTML response, so search engines and AI assistants read the same content your visitors see.

When Bubble is still fine

Apps that live behind a login, where search and AI visibility don’t matter. Public marketing pages can also move to a separate coded site while the app stays on Bubble.

Sources: Vercel and MERJ: the rise of the AI crawler (December 2024); Google Search Central: JavaScript SEO basics

Why do Bubble workload unit costs keep growing?

Bubble bills server work in workload units (WU): workflows, database searches, page loads and API calls all use them. Web plans include 175K WU a month on Starter ($29), 250K on Growth ($119) and 500K on Team ($349), billed annually. Above that you buy a workload tier or pay overages, or switch overages off and cap the app at what you’ve paid for. The hard part isn’t the price list. It’s predicting usage: one inefficient workflow or a traffic spike can multiply it.

How code solves it

You pay for hosting and database resources directly, and every query can be measured, cached and tuned. Costs don’t disappear; they become infrastructure you can see and control.

When Bubble is still fine

Apps with stable usage well inside their plan. Fixing WU-heavy workflows is usually cheaper than migrating, and it’s often where we start.

Sources: Bubble pricing (web plans, checked October 15, 2026); Bubble blog: what is workload

Can you export a Bubble app’s code?

No. Bubble’s manual says Bubble apps can only run on the Bubble platform and can’t be exported as code. Your data can leave: as CSV files or through the Data API. So a migration is a rebuild, with your live Bubble app as the specification.

How code solves it

You get source code in your own GitHub, a standard PostgreSQL database, and every account in your name. You can change developers or hosts without rebuilding again. Next.js, Supabase and Stripe are still vendors, but replaceable ones.

When Bubble is still fine

Products still validating an idea, or apps that aren’t strategically critical. There, lock-in is a fair trade for speed.

Sources: Bubble manual: application and data ownership; Bubble manual: exporting data

Can Bubble handle large amounts of data?

Up to documented limits. A sorted search returns at most 50,000 things, a list stored on a thing holds at most 10,000 items, a single thing is capped at 20 MB, and a search can time out after 10 seconds. Bubble keeps improving here: in September 2025 it reported searches about 50% faster for affected workloads. Most apps never hit these limits.

How code solves it

PostgreSQL gives you indexes, joins, query plans, transactions and direct SQL. Heavy searches and reports can run as background jobs instead of blocking the page.

When Bubble is still fine

Moderate data volumes with simple queries, built by a developer who designs data types with Bubble’s limits in mind.

Sources: Bubble manual: hard limits; Bubble community update, September 2025

What moves, and what Bubble can’t export

Data leaves Bubble. Code doesn’t. Here is what that means for each part of your app.

Moves to the new app

  • Database records. Exported as CSV or through the Data API, mapped to a new schema. We keep each Bubble ID so every record can be reconciled.

  • Files and images. Copied to new storage and checked one by one, so no attachment is lost.

  • Pages and design. Rebuilt in code. The design can match what users know, or improve where it should.

  • Workflows and logic. Rewritten as tested code, after we read how your Bubble workflows actually behave.

  • Privacy rules and roles. Turned into database-level security and role checks.

  • Stripe and integrations. Stripe customers and subscriptions stay in your Stripe account; IDs are remapped and webhooks rebuilt.

  • URLs and SEO. Public URLs kept or redirected, so search rankings carry over.

Can’t be exported

  • Source code. It doesn’t exist outside Bubble. The new app is written from scratch.
  • User passwords. Stored as one-way hashes. Users set a new password once or sign in through SSO.
  • Plugins. Replaced with code libraries or custom functions.
  • Editor history and logs. Version history and server logs stay in Bubble. Export what you need before you close the app.

Sources: Bubble manual: application and data ownership; Bubble manual: the Data API; Bubble manual: user accounts

Three paths, not one

A full rebuild isn’t always the answer. Often the right first move is smaller.

Path 1

Optimize Bubble

Best for
Apps where Bubble still fits, but costs or speed hurt.
What we do
We audit workflows, data types, searches, plugins and page loads, then fix what burns workload units.
Risk
Low. The app stays where it is.
Outcome
Lower WU, faster pages, and a clear answer on whether you need to move at all.
Path 2

Phased migration

Best for
Live products that can’t afford a big switch.
What we do
We move one bottleneck to code first (public pages, search, reports or background jobs) and connect it to Bubble. Then the next module.
Risk
Medium. Two systems run side by side for a while.
Outcome
Value from the first phase. Bubble is retired when it makes sense, or kept for the parts that work.
Path 3

Full rebuild

Best for
Apps hitting several limits at once, or needing full ownership.
What we do
We rebuild the whole app in code, migrate data and users, and switch over in one planned cutover.
Risk
Highest upfront, reduced by parity tests, a dry run and a rollback plan.
Outcome
One codebase and database you own end to end.

The stack we move you to

A common, well-documented stack, so any good developer can work on it after us. We adjust it when your app needs something different.

  • Next.js and TypeScript

    Server-rendered public pages, fast app screens, one language across the product.

  • PostgreSQL on Supabase

    A standard database with auth, file storage and row-level security. Portable to any Postgres host.

  • Background jobs

    Scheduled and heavy work (reports, imports, AI processing) runs off the page.

  • Stripe

    Your existing Stripe account, with webhooks rebuilt and tested.

  • Hosting you choose

    Vercel by default, or your own cloud if your rules require it.

  • GitHub, CI and tests

    Code review, automated checks and tests on the workflows that matter.

How a migration runs, step by step

Your Bubble app stays live until the new one has passed the same checks with your real data.

  1. 1

    Audit

    Pages, workflows, plugins, privacy rules, integrations, scheduled jobs and WU usage.

  2. 2

    Specification

    Target data model, a feature-parity list, and what to drop instead of rebuilding.

  3. 3

    Foundation

    Repository, database, auth, hosting and CI, set up in your accounts.

  4. 4

    Rebuild

    Module by module, while your Bubble app stays live for users.

  5. 5

    Verification

    Records, files, permissions and Stripe references reconciled; key workflows tested side by side.

  6. 6

    Dry run

    A full rehearsal of the data migration on a copy, timed and checked.

  7. 7

    Cutover

    Final data sync, domain switch and password reset or SSO, at a low-traffic time.

  8. 8

    Support

    Monitoring and fixes, with a rollback path kept until things are stable.

What a migration costs and how long it takes

Page count says little. Cost and time follow the logic behind the pages. Small MVPs usually take weeks; established products with payments, roles and years of data take months.

For a rough market view: other Bubble migration agencies publish ranges of 6–8 weeks for a small MVP, 2–4 months for a moderate app and 3–6 months for a complex live product, with full-migration budgets often around $30,000–$80,000. Optimizing Bubble or moving one feature costs far less.

We give you a timeline and a quote after we’ve assessed your app, not from a page count.

What drives the cost

  • Number and complexity of workflows
  • Roles, permissions and privacy rules
  • Data relationships and data quality
  • Scheduled jobs and backend workflows
  • Plugins and external APIs
  • Payments and subscriptions
  • Admin tools and reporting
  • How the cutover has to work

Stay on Bubble or move to code?

Bubble isn’t insecure: it holds SOC 2 Type II. It keeps shipping too, including a native mobile builder in public beta since June 2025. The question is whether its trade-offs still fit your product.

Bubble still fits when

  • You’re still validating the product
  • The app is internal or behind a login
  • WU usage is stable and inside your plan
  • Your team ships quickly in Bubble
  • Data volumes are moderate
  • Bubble’s mobile beta covers your mobile plans

Code fits better when

  • Public pages must rank and be readable by AI
  • WU costs rise faster than revenue
  • You need to own the source code
  • You need Git, CI and automated tests
  • Data volumes press against hard limits
  • You need HIPAA compliance, which Bubble doesn’t recommend its platform for

Sources: Bubble security; Bubble manual: HIPAA; Bubble blog: native mobile beta

Our own migration

We moved this site off Bubble too

Until September 2026, mindforapps.com ran on Bubble. We rebuilt it in Next.js and Supabase: case studies, solutions, templates, plugins, FAQs and the admin panel our team uses to edit them. Images moved to Supabase Storage, and old Bubble URLs redirect to their new pages.

The result you can check yourself: our homepage now gives an AI crawler 2,319 readable words without running any JavaScript.

Words an AI crawler reads

2,319

mindforapps.com today, Next.js

1–2

Typical Bubble app in our test (see method)

Bubble migration questions

No. Bubble’s manual says Bubble apps can only run on the Bubble platform and there is no way to export an app as code. Moving off Bubble means rebuilding the app, using the live Bubble app as the specification. Your data and files can be exported.

Yes. Each data type can be exported as CSV, or records can be pulled through Bubble’s Data API with scripts, which suits large or incremental exports. Relationships between data types have to be mapped, and we keep each record’s Bubble ID so everything can be reconciled after the move.

No. Bubble stores passwords as salted one-way hashes, and the plain passwords can’t be exported. Users either set a new password once, keep signing in through Google or another SSO provider, or move over through a transitional login that needs a careful security review.

Users who sign in with an email and password usually do, once. We plan the message, timing and reset flow so it feels like a routine security step. Users who sign in with Google, Apple or another SSO provider can usually keep doing so.

Yes. The Bubble app keeps running while the new app is built and tested. The switch happens in a planned cutover with a final data sync at a low-traffic time. Expect a short freeze on changes during the cutover, not weeks of downtime. We agree the plan and the rollback steps before the day.

For a while, yes. A coded frontend can read and write Bubble data through the Data API, which gets you server-rendered pages sooner. Workload units, Bubble’s database limits and lock-in stay, so we treat this as a bridge rather than the end state, unless you decide to keep it.

Yes, and it’s often the best first step. Search, reports, AI processing or background jobs can move to code and connect to Bubble while the rest of the app stays where it is. You get the improvement without committing to a full rebuild.

It depends on workflows, data and integrations more than on page count. Small MVPs usually take weeks; established products with payments, roles and lots of data take months. Other agencies publish ranges of 6–8 weeks for a small MVP and 3–6 months for a complex live product. We give a timeline after we’ve assessed your app.

Cost follows complexity: workflows, roles and permissions, data relationships, scheduled jobs, plugins, external APIs, payments, admin tools and the cutover plan. Budgets published by other agencies for full migrations are often around $30,000–$80,000. Small MVPs cost less, and optimizing Bubble or moving one feature costs much less. We quote after we’ve seen your app.

Customers, subscriptions and payment methods stay in your own Stripe account. We map Stripe IDs to the new database, rebuild webhook handling, and switch billing only after records reconcile, ideally after a full billing cycle running side by side.

Usually Next.js with TypeScript for the app and public pages, PostgreSQL on Supabase for the database, auth and file storage, background jobs for heavy work, Stripe for payments, and hosting on Vercel or your own cloud. Everything sits in your own GitHub and accounts.

No. It’s a strong default when public pages need to load fast and be readable by search engines and AI assistants. An internal tool behind a login may be better served by a simpler setup. We choose the stack per app and explain why.

No. Many apps run well on Bubble for years. If workload costs, speed or limits are the problem, optimizing the Bubble app is often cheaper. Migration makes sense when several limits hit at once, or when you need code ownership, server-rendered pages or infrastructure Bubble can’t provide.

Yes. Googlebot renders JavaScript, so Google can index Bubble pages, although rendering is queued and Google still recommends server-side rendering or pre-rendering for important content. Page speed and correct meta tags still matter.

Often not. The main AI crawlers download JavaScript but did not run it in Vercel and MERJ’s December 2024 analysis. Bubble builds most page content with JavaScript, so in our October 2026 test three Bubble apps showed an AI crawler only 1–2 words of text. Server-rendered pages put the full text in the HTML.

Not sure which path fits your app?

Tell us about your Bubble app. We’ll tell you whether to optimize it, move part of it, or rebuild it, and why.