The Hybrid Migration: Move Your Customer-Facing App to Code and Keep Admin on Bubble

A hybrid Bubble migration moves the parts of the product that need more control to custom code while leaving the parts that still work well on Bubble. In practice, that often means rebuilding the customer-facing application while keeping admin dashboards, internal CRM tools, reporting screens, and low-traffic operations on Bubble.

For a live product, this can be a much easier decision to justify than a full rewrite.

You spend money rebuilding the parts that are actually causing problems. Your customers get the benefits of the new architecture. And your internal team keeps using tools that already do their job.

It isn’t automatically simpler, though. Once Bubble and custom code run side by side, you have two systems to connect and maintain.

The question is whether that added integration work costs less than rebuilding everything at once.

If you’re still deciding whether moving to code makes sense at all, start with our Bubble vs. custom code comparison.

What is a hybrid Bubble migration?

A hybrid migration is a partial rebuild. Instead of replacing the entire Bubble application, you move selected parts to custom code and keep the rest running on Bubble. The usual split is customer-facing functionality on the new stack and lower-traffic internal tools on Bubble.

Imagine a SaaS product with:

• customer signup and onboarding;
• the main product interface;
• billing;
• an admin dashboard;
• an internal CRM;
• support tools;
• reporting;
• manual operations workflows.

Maybe customers are running into performance problems in the main application. Workload consumption keeps climbing. An enterprise prospect needs a technical requirement the current setup can’t comfortably support.

But the admin dashboard?

Your operations team opens it a few times a day. It works. Nobody is complaining.

Rebuilding that dashboard simply because you’re rebuilding the customer application may add weeks of work without solving a meaningful problem.

A hybrid migration draws the boundary differently:

Move what needs to move. Leave the rest alone.

In software architecture, this isn’t a particularly unusual idea. It follows the same basic logic as the Strangler Fig approach to legacy modernization: replace an existing system gradually rather than attempting one large cutover. Martin Fowler describes the pattern as creating the new system around the edges of the old one and moving functionality across in manageable pieces.

A Bubble migration can work the same way.

Why can a partial Bubble migration be safer than a full rebuild?

A partial migration reduces the amount of software you have to replace at once. That usually means fewer workflows to recreate, fewer screens to validate, and a smaller cutover surface. But the benefit depends on whether the application has a clean boundary between what moves and what stays.

Big rewrites become difficult partly because of scope.

Every screen needs rebuilding. Every workflow needs understanding. Every edge case needs testing. Every integration needs reconnecting.

And the longer the project runs, the more likely the live product changes while you’re rebuilding it.

A hybrid migration narrows the job.

If 70% of the business problem lives in 30% of the application, moving that 30% first may make far more sense than treating every page equally.

This is also why incremental replacement is an established modernization strategy rather than a Bubble-specific workaround. Fowler’s work on the Strangler Fig pattern emphasizes breaking a replacement into smaller pieces so that investment and value can happen gradually rather than depending on one big cutover.

There are three practical advantages.

You rebuild less

An internal dashboard may contain dozens of pages and workflows while generating almost none of the problems behind the migration.

Leaving it alone removes that work from the first phase.

The risky cutover gets smaller

Instead of switching the entire business from one application to another overnight, you move a defined set of customer journeys.

That makes testing, rollback, and monitoring easier to reason about.

Internal users are usually more forgiving

If an admin report takes an extra second to load, your operations manager may barely notice.

If checkout takes an extra second, customers might.

The same technical limitation can have very different business consequences depending on who encounters it.

That’s why we don’t decide what to migrate based on page count alone.

How do you decide what moves to code and what stays on Bubble?

Use a business rule: move functionality when the current architecture is creating a measurable cost, risk, or sales blocker. Keep functionality on Bubble when rebuilding it would cost more than the problem it solves.

That’s also how we approach scoping a migration.

Here’s what that looks like in practice.

Move high-traffic customer journeys

Signup, onboarding, search, checkout, dashboards customers use every day, and the core product loop are usually the first places worth examining.

These are the paths where performance matters most.

They’re also where growing traffic can translate into growing workload consumption.

Don’t assume they need to move. Measure them first.

But if most of your Bubble workload comes from customer traffic and those same pages are creating performance complaints, the customer-facing application is a logical candidate for migration.

Move long-running or compute-heavy processes when Bubble is becoming the constraint

AI processing, large imports, report generation, bulk operations, and slow third-party services can become awkward when they require increasingly complicated workflow chains.

That doesn’t necessarily mean the UI needs rebuilding.

Sometimes the better architecture is to move the heavy processing into a coded backend and let Bubble continue handling the interface.

This is an important point: hybrid doesn’t only mean splitting pages.

You can split responsibilities.

Bubble can remain the interface for a particular workflow while custom infrastructure handles the work behind it.

Move functionality that’s blocking a real enterprise requirement

If a customer needs a specific deployment model, identity setup, audit capability, data architecture, or other technical control you can’t provide today, isolate the requirement.

Then ask how much of the application actually needs to change to satisfy it.

Don’t rebuild 100% of a product to solve a problem that exists in 20%.

If enterprise requirements are driving the conversation, review the security and compliance considerations before deciding where the boundary should sit.

Keep internal admin tools on Bubble when they still work

Admin dashboards are often good candidates to leave alone.

They usually have:

• relatively few users;
• predictable usage;
• lower performance requirements;
• little or no direct impact on customer experience;
• a surprisingly large amount of functionality.

That last point matters.

Internal software tends to accumulate.

Refund tools. User management. Account overrides. Support screens. Reporting. Data corrections. Content management.

Rebuilding all of it can consume a significant part of a migration budget without changing anything customers see.

If the tools work, there needs to be a reason to move them.

Keep low-traffic operations workflows when migration adds no real value

The same applies to internal reporting, occasional data fixes, manual approval flows, and tools used by a handful of employees.

“It’s still on Bubble” isn’t a problem.

If it costs very little, works reliably, and doesn’t block the business, leaving it there may be the sensible engineering decision.

How can Bubble and a custom-coded app work together?

There are four common approaches: use a new database as the source of truth, access Bubble’s database through the Data API, synchronize the systems with events, or separate the applications by route or subdomain. The right choice depends on how tightly the two sides need to share data and authentication.

Bubble’s Data API allows external systems to search, read, create, modify, and delete records in a Bubble database. Bubble can also make outbound REST API requests using its API Connector. Those two capabilities make several hybrid architectures possible.

Here’s how the main options differ.

Use Postgres as the source of truth

Best when: you’re treating hybrid as the first stage of a longer migration.

The new application uses a conventional database such as Postgres as the primary data store. Bubble accesses the data it needs through an API rather than owning the canonical version of that data.

Conceptually:

Customer app → API → Postgres ← API ← Bubble admin

This creates a clean long-term boundary.

The customer application and Bubble admin tools can use the same underlying business data without making the new application dependent on Bubble’s database.

Workload impact: Bubble activity still consumes workload where Bubble is doing work, and outbound/API-related operations should be measured rather than assumed to be free. The exact consumption depends on the workflows and calls involved.

Main failure mode: you underestimate how much existing Bubble logic assumes direct access to Bubble data.

Moving the source of truth sounds simple on an architecture diagram. In a mature app, workflows, privacy rules, searches, plugins, and calculated values may all depend on the current database.

This option usually requires more work upfront, but it leaves you with a cleaner path if Bubble will eventually become a smaller part of the system.

Put Bubble’s Data API in front of the existing database

Best when: you want to move the customer-facing application first without migrating the database immediately.

The new coded application communicates with the existing Bubble database through Bubble’s Data API.

Bubble documents the Data API as a RESTful interface that allows external applications to search, read, create, modify, and delete database records.

Conceptually:

New customer app → Bubble Data API → Bubble database

Meanwhile, the existing admin application keeps working against the same data.

This can get a hybrid architecture running relatively quickly because you don’t have to move the database on day one.

The downside is that your new application is still dependent on Bubble for its data layer.

Workload impact: calls that cause Bubble to perform work can contribute to Bubble workload, so high-volume paths need to be modeled against real usage rather than treated as an unlimited free API layer.

Main failure mode: the temporary architecture becomes permanent.

If the long-term goal is independent infrastructure, make sure there’s a plan for moving the data layer later. Otherwise you’ve moved the frontend but kept a critical dependency underneath it.

Synchronize the two systems with events

Best when: the two sides don’t need every change immediately.

Bubble and the new application maintain separate data stores and send relevant changes between them.

For example:

1. A customer updates their company details in the coded application.
2. An event is created.
3. A worker processes it.
4. The Bubble admin system receives the updated information.

The same can happen in the other direction.

This works well when the systems are loosely coupled and a short synchronization delay is acceptable.

Workload impact: Bubble still does work when events trigger Bubble workflows or database operations. The actual workload depends on event volume and what each event causes Bubble to do.

Main failure mode: data disagreement.

• What happens if the same customer record changes in both systems at almost the same time?
• Which one wins?
• What happens if an event fails?
• How do you replay it?
• How do you know that the two systems agree?

Event-driven architectures can work very well, but synchronization isn’t something you bolt on at the end.

Someone has to own reconciliation.

Split the applications by route or subdomain

Best when: customer and internal functionality already have a clear boundary.

A common setup looks like this:

app.yourcompany.com   → custom code
admin.yourcompany.com → Bubble

This is easy for users to understand and gives each application a clear job.

The hard part is usually authentication.

• If an employee moves between the coded application and Bubble, do they log in twice?
• If not, which system owns identity?
• How are roles synchronized?
• How are sessions handled?
• How do you revoke access everywhere at once?

These questions need answers before launch, not after.

Workload impact: simply routing traffic to different applications doesn’t itself create Bubble workload. Activity inside the Bubble side still does.

Main failure mode: treating authentication as a small integration task.

It isn’t.

For technical teams evaluating these options, our CTO and engineering resources go deeper into the architecture behind a migration.

What are the trade-offs of a hybrid Bubble migration?

The biggest tradeoff is simple: you’ve reduced the rebuild, but you’ve introduced a boundary between two systems. That boundary now needs to be designed, tested, monitored, and owned.

There are five things we make sure teams understand before choosing hybrid.

You now deploy two applications

The coded application has its deployment process.

Bubble has its own.

A customer issue may involve one side, the other side, or the integration between them.

That isn’t necessarily a problem. But it is more operational complexity than running one application.

Data consistency becomes your responsibility

If both applications can change the same information, you need rules.

• Which system is the source of truth?
• What happens when updates conflict?
• What happens when synchronization fails?
• How do you detect missing records?

If nobody can answer those questions, the architecture isn’t ready.

Authentication needs to be designed early

Auth is one of the easiest parts of a hybrid architecture to underestimate.

Ideally, both systems trust the same identity provider or there is another deliberate mechanism for maintaining identity across the boundary.

Don’t finish two applications and then ask how users will move between them.

Design identity first.

You’re still paying for Bubble

Hybrid isn’t a way to eliminate the Bubble bill overnight.

You’re still using the platform.

What may change is why you’re paying for it.

If most workload was generated by high-volume customer activity and that activity moves to the coded application, Bubble usage may fall substantially. If your workload is actually coming from heavy internal processes, the saving may be much smaller.

Use the workload unit calculator rather than guessing.

The same applies to migration cost. A partial rebuild can cost considerably less than rebuilding everything, but there is no responsible universal percentage. The savings depend on what stays behind and how difficult the integration boundary is. Our published price ranges provide a starting point, but the application itself still needs to be scoped.

Someone has to own the boundary

This may be the most important point in the article.

• An API nobody understands eventually breaks.
• A synchronization process nobody monitors eventually misses something.
• An undocumented authentication bridge eventually becomes the thing everyone is afraid to change.

Hybrid works when the boundary is treated as part of the product architecture, not temporary plumbing everyone plans to deal with later.

When is a hybrid migration the wrong choice?

A hybrid migration is the wrong choice when splitting the application creates more complexity than it removes. If the same logic has to exist in both systems, the Bubble side is already the main problem, or you’re planning to remove Bubble almost immediately anyway, a clean full migration may make more sense.

Here are the situations that make us cautious.

The internal tools are the problem

If your admin and operations workflows are generating most of the workload, causing performance problems, or becoming impossible to maintain, leaving them on Bubble doesn’t solve much.

You’d be preserving the part that caused the migration.

The two halves can’t be separated cleanly

Suppose nearly every customer action immediately triggers admin logic, which triggers another customer workflow, which updates data used by both sides.

You can split that architecture.

The better question is whether you should.

If the integration layer becomes more complicated than rebuilding the remaining functionality, hybrid has lost its advantage.

Your Bubble costs come mostly from what you’re planning to keep

If cost reduction is the reason for migrating, check where the workload is actually coming from.

Moving a lightweight customer interface won’t help much if expensive backend and internal workflows remain on Bubble.

Measure first.

You’re definitely removing Bubble in six months

Sometimes a hybrid phase is worth it because it lowers cutover risk.

Other times it means spending months building an integration layer that will immediately be thrown away.

If a full migration is already funded, scoped, and realistically close, compare the cost of the temporary architecture with the risk it actually removes.

Don’t build a bridge just because hybrid sounds safer.

Is hybrid migration just a temporary workaround?

Not necessarily. A hybrid architecture can be either a permanent split or a stage in a gradual full migration. The important part is deciding which one you’re building before you design the boundary.

If the goal is eventually to leave Bubble, build the new architecture so functionality can move across that boundary over time.

That is essentially the Strangler Fig approach.

The old application keeps working while individual capabilities move into the new system. The new system gradually takes on more responsibility until the old one can eventually be retired. Fowler notes that this approach allows investment and value to happen gradually, although it doesn’t make modernization inherently easy.

A sensible sequence might be:

You don’t have to decide today that Phase 5 will happen.

You do need to avoid building Phase 1 in a way that makes Phase 2 impossible.

You don’t have to rebuild the part that still works

A full rebuild is easy to understand.

Old application over here. New application over there. Move everything and switch.

It’s also a lot to ask of a live business.

If customers are using the product every day, your team is still shipping features, and revenue depends on keeping the application running, there is nothing inherently better about moving everything at once.

Start with the reason you’re considering migration.

• Which part of the application is actually costing you?
• Which part is losing deals?
• Which part is frustrating customers?
• Which part is consuming the workload?
• Which part needs technical control you don’t have today?

Move that.

Then look at what’s left.

If your admin dashboard quietly does its job for six employees every day, it doesn’t need to become a Next.js application just so you can say you’re completely off Bubble.

And if you eventually decide to move it too, you can.

That’s the point of doing the split properly.