Moving from Bubble to Next.js still leaves the backend to design

Next.js is a sensible frontend target for a lot of Bubble migrations.

It gives you React, routing, layouts, server rendering where it helps, a good deployment story, and a codebase that normal engineers can work with. For a serious Bubble app, that can be a big improvement over having product logic spread through pages, reusable elements, custom states, workflows, plugin settings, and privacy rules.

The mistake is treating "Bubble to Next.js" as the whole migration plan.

Bubble is an application platform. Next.js is primarily the web app layer. It can run server code, and that is useful, but a real product still needs a backend architecture: database, auth, permissions, file storage, background jobs, webhooks, realtime behaviour, observability, and a release process. For NQU-style migrations, the backend is often Supabase or Convex, depending on the shape of the app.

The useful planning question is what the full replacement system needs to be.

Next.js Is The App Layer

In Bubble, the page, database, workflows, auth, files, API Connector calls, privacy rules, scheduled workflows, and plugin behaviour all sit inside one platform. That is part of why Bubble is so productive early on. You can build a working product without deciding where every responsibility should live.

In a Next.js app, those responsibilities need clearer homes.

The UI becomes React components. Routes become pages, layouts, dynamic routes, server/client boundaries, and navigation rules. Form submissions might use server actions, API routes, or a backend function. Authentication needs a provider. Permissions need explicit checks. Background work needs somewhere to run. Files need storage. Data needs a model your team can query, test, and change.

Next.js can handle some server-side work, but it should not become a dumping ground for everything Bubble used to do. A serious app usually needs a backend that is designed deliberately rather than accumulated around page code.

The Backend Still Needs To Be Chosen

Supabase is a common fit when the app wants Postgres, SQL, row-level security, auth, storage, and a fairly conventional backend shape. It can work well when the product benefits from relational data and the team is comfortable owning database structure directly.

Convex is a common fit when the app has realtime product behaviour, lots of app logic around data changes, collaborative state, reactive UI, or a team that wants backend functions and data access patterns to stay close to the product code. It can also be a good fit for teams that want to move quickly without hand-rolling as much backend plumbing.

There are other options: a custom Node backend, Rails, Django, Laravel, serverless functions, queues, managed auth, object storage, search services, and so on. The right answer depends on the app.

The main thing is to decide intentionally. If the old Bubble app has complex permissions, heavy reporting, private files, scheduled jobs, customer-specific edge cases, or workflow chains that affect revenue, the backend choice is one of the most important migration decisions.

What Actually Has To Be Rebuilt

The visible screens are only one part of a Bubble to Next.js migration.

The UI has to become React components. Bubble pages, reusable elements, repeating groups, popups, conditionals, and responsive rules need to turn into a component system developers can maintain.

Routes need to be designed properly. Bubble pages often combine several modes or user journeys inside one page with conditionals and custom states. In Next.js, you need to decide which pages, dynamic routes, layouts, and server/client boundaries make the product easier to understand.

The data model needs redesign. Bubble data types may map into Supabase tables, Convex tables, Postgres models, or another backend. The model should be based on the product rather than the old Bubble structure.

Authentication and permissions need explicit architecture. Bubble login, privacy rules, role fields, page restrictions, and workflow conditions all need to become a clear access model in the new stack.

Workflows need backend homes. Some Bubble workflows become server actions, API routes, Convex functions, Supabase Edge Functions, service functions, queue jobs, webhooks, or database transactions. The important behaviour needs to be preserved, while the implementation can become cleaner.

Files need a storage plan. Bubble file uploads, private documents, generated PDFs, and imported files need to move somewhere sensible, usually object storage or the backend's storage layer with access rules that match the product.

Integrations need to be rebuilt deliberately. API Connector calls, plugin actions, Stripe flows, email providers, CRMs, webhooks, analytics, AI services, and internal tools should be inventoried before anyone estimates the migration.

Admin tools need respect. They are often ugly, but they run the business. Support dashboards, correction flows, exports, reporting pages, and operational buttons need to be reviewed as real product surfaces.

Bubble To Next.js Stack Checklist

Before the rebuild starts, decide where each responsibility lives:

• frontend: Next.js routes, layouts, React components, forms, client state
• backend: Supabase, Convex, custom API, or another service layer
• data: schema, relationships, migration references, reporting model
• auth: login, sessions, organisations, memberships, roles, impersonation
• permissions: tenant boundaries, record access, admin overrides, private files
• jobs: scheduled workflows, retries, queues, webhooks, long-running work
• files: uploads, generated documents, signed access, legacy file URLs
• operations: tests, logging, deployments, rollback, support tools, handover

If those choices are vague, the project is still in discovery. Generating React components will not fix missing backend decisions.

Claude Code Helps After The Plan Exists

Claude Code and similar tools can be genuinely useful during a migration. They can draft components, move code around, generate tests, write import scripts, help with schema ideas, and speed up implementation once the architecture is clear.

The problem is using an LLM as if it can understand a Bubble app by being handed screenshots, exports, or a vague feature list.

Bubble and Next.js represent software differently. Bubble behaviour lives in workflows, conditions, custom states, page data sources, backend workflows, reusable elements, privacy rules, plugin settings, API Connector configuration, and old admin habits that may never have been documented. A lot of the important logic is invisible from the front end.

Next.js has different practices: components, server/client boundaries, backend services, database models, typed functions, auth middleware, environment configuration, tests, deployment pipelines, and observability. A good migration needs translation between those models, not blind conversion.

An LLM can write code for a well-understood target. It cannot reliably decide which Bubble behaviours are revenue-critical, which old fields are tech debt, which admin workflow keeps support alive, or which privacy rule is compensating for a messy data model.

That means the app needs care and attention before the code generation stage. Someone has to inspect the Bubble source, understand the product logic, choose the backend shape, design the data model, and decide what should be preserved, improved, or removed.

Avoid Copying Bubble Patterns Into Next.js

A like-for-like rebuild can feel safer because everyone can compare the old app to the new app screen by screen. That comparison is useful for QA, but it should not control the architecture.

Bubble apps often contain patterns that made sense inside Bubble and make less sense in code. A page might use custom states because that was the easiest way to coordinate UI state in the editor. A backend workflow might handle five unrelated jobs because adding one more action was faster than designing a cleaner process. A data type might contain fields that only exist to make one repeating group easier to filter.

Those choices should be reviewed during the migration. Some behaviour must stay identical because customers rely on it. Some behaviour should be preserved at the product level while the implementation changes underneath. Some old workarounds should disappear.

This is also where the backend choice matters. A Supabase app, a Convex app, and a custom API can all support the same product, but they lead to different data access patterns, permission models, realtime behaviour, and deployment habits.

Data Migration Needs Proof

Moving the UI is only part of the migration. The data has to move into a model the new backend can own.

For a serious app, data migration should include exports, transformation scripts, file migration, relationship checks, role checks, record counts, sample audits, and reconciliation against business reports. You want to catch the quiet failures before customers do.

The awkward cases matter most: cancelled customers, deleted users, legacy plans, imported records, manually edited invoices, old workflows, and records created before the app had its current structure.

A new Next.js frontend can look right while reporting is wrong, permissions are looser than Bubble's privacy rules, or the backend has no clear way to validate moved data. In those cases, the migration is still unfinished.

Roll Out In Stages Where You Can

For live apps, a staged rollout is usually safer than a single switchover day.

The right sequence depends on the product. You might start with reporting, admin tools, onboarding, one customer cohort, one workflow-heavy module, or a new user path while existing users stay on Bubble for a while. The order should be based on business risk and data dependencies.

This is the same migration philosophy behind our broader Bubble to code migration advice: understand the app first, keep the business moving, and validate each stage before widening the rollout.

There are cases where a full cutover is fine. Smaller apps, simpler internal tools, or products with low usage may not need a complicated transition. If the app is revenue-critical, has meaningful data, or supports paying customers every day, it is worth being careful.

The Sensible First Step

If you are considering Bubble to Next.js, start with an assessment rather than a rebuild estimate.

A useful assessment should identify the critical workflows, data model, permissions, integrations, scheduled jobs, files, admin tools, backend requirements, and rollout risks. It should also tell you whether Next.js with Supabase, Next.js with Convex, or a different stack is the right target for your app.

That might sound slower than asking Claude Code to generate the new app, but it usually saves time. A confident estimate made before anyone has inspected the Bubble app is often just a guess with nicer formatting.

If you want help working out whether a Bubble to Next.js migration makes sense for your app, start with our migration assessment. The goal is to understand the system properly, then decide the safest path to code from there.

Questions This Guide Answers

Can a Bubble app be converted directly to Next.js?

A direct conversion will miss too much. The UI, backend, workflows, data model, permissions, files, integrations, jobs, and admin behaviour need to be understood and rebuilt deliberately.

Does a Bubble to Next.js migration still need a backend?

Yes. Next.js is primarily the web app layer. A serious migration still needs a backend for data, auth, permissions, files, background jobs, webhooks, and realtime behaviour. Supabase and Convex are common options.

Can Claude Code migrate a Bubble app to Next.js?

Claude Code can help once the migration plan is clear, but it cannot reliably infer all Bubble workflows, privacy rules, plugin behaviour, data assumptions, and admin edge cases from a vague brief or screenshots.