How to Migrate from Bubble to Next.js: What the Process Actually Looks Like

What you're actually doing when you migrate

The most important thing to understand before starting: you are not converting Bubble to code. Bubble doesn't export code. The work product from your Bubble app doesn't transfer to the new stack.

What transfers:

• The product knowledge earned from building and iterating in Bubble
• The user flows and UX decisions
• The business logic, documented and understood
• User data, exported from Bubble and migrated to the new database

What doesn't transfer:

• Any visual or workflow work built in Bubble's editor
• Bubble-specific integrations (these rebuild against the same third-party APIs)

This sounds like a big loss. In practice, the rebuild goes faster than the original build because the product is already well-understood. You're not discovering what to build. You're building what you already know works.

Start with a Blueprint

A Bubble migration without a Blueprint is expensive and usually produces a worse result than staying in Bubble.

A Blueprint is a paid discovery engagement: mapping the existing product, redesigning the data model for a relational database, scoping the rebuild, identifying what to migrate first, and deciding whether a full migration or selective migration makes more sense.

Bubble's data structure doesn't map directly to SQL. The migration isn't an export and import. It requires intentional redesign. Cutting this step short is the most common cause of migrations that take twice as long and cost twice as much as expected.

The migration stack

Our default migration stack:

• Frontend: Next.js deployed on Vercel. React-based, fast builds, straightforward deployment pipeline.
• Database: Supabase (PostgreSQL). Starts at $25/month on Pro. Dedicated Postgres, authentication, storage, and realtime built in.
• Backend: Depends on the product — Next.js API routes for simpler server logic; Convex for products that need real-time reactive data or complex server-side logic ($25/month Professional); Cloudflare Workers for AI agent orchestration and edge compute.

The four workstreams

1. Data model redesign

Bubble stores data in a document-like structure with linked things. Supabase uses relational tables with foreign keys, indexes, and constraints. They're different paradigms.

Don't map Bubble data types directly to SQL tables. Use the migration as the opportunity to redesign the data model correctly for a relational database. Common patterns that need rethinking: Bubble's "list of things" fields often become junction tables, nested data structures need normalization, and implicit relationships need explicit foreign keys.

A good data model design takes a week of careful work. Cutting this short creates the same performance problems in the new stack that may have contributed to the migration.

2. Frontend rebuild in React

The Next.js frontend is built in React. Key decisions:

• Styling: Tailwind CSS for most teams
• State management: React Query or SWR for data fetching
• Authentication: Supabase Auth or NextAuth
• UI components: ShadCN/UI or Radix for accessible, customizable components

The frontend rebuild is the most visible part of the migration and often where teams underestimate complexity. Bubble's visual builder handles a lot of responsive behavior and state management implicitly. In React, this needs to be coded explicitly.

3. Backend logic rewrite

Bubble's backend workflows and API Connector integrations need equivalents in the new stack. Simple business logic moves to Next.js API routes. Complex server logic or real-time features move to Convex. AI agent logic and edge compute move to Cloudflare Workers.

4. Data migration and cutover

Bubble provides data export in CSV format. The migration from Bubble's data structure to the new relational schema requires a migration script. Plan for data cleaning (test data, legacy fields), schema transformation, validation of record counts and data integrity after migration, and a rollback plan.

For live products with active users, plan a maintenance window or parallel-run cutover. Cutting over without a plan creates data consistency problems.

What the migration won't fix

A migration to custom code won't fix an unclear product direction. If the product isn't performing in the market, a new stack won't change that. Migration is an infrastructure decision, not a product strategy decision.

It also won't fix a bad data model. If the Bubble data model was poorly designed and those patterns replicate in PostgreSQL, you get the same problems in a different environment. The Blueprint step exists to prevent this.

Frequently asked questions

How much does a Bubble to Next.js migration cost?

A moderate-complexity app (20 to 30 data types, 10 to 15 key user flows, 3 to 5 integrations) typically costs $30,000 to $80,000 to rebuild. Simpler products cost less. Complex products with many integrations and large data models cost more. The Blueprint adds to the total but is the most important investment in keeping the migration in scope.

Can I use Supabase as a drop-in replacement for Bubble's database?

Not directly. Supabase is PostgreSQL, which is a different paradigm from Bubble's document-like data model. You can migrate data from Bubble to Supabase, but the schema needs to be redesigned for relational structure.

What happens to my Bubble subscription during the migration?

Keep it active until the new stack is live in production and stable. Plan for one to two months of parallel operation and budget for the overlap.

Should I migrate all at once or in phases?

Depends on the product. Selective migration — moving the highest-constraint parts while keeping stable features in Bubble — reduces risk and keeps the team shipping. A big-bang cutover is simpler from a data consistency perspective. We make this call in the Blueprint.