Gradual Migration from Bubble: The Strangler Fig Approach

The standard Bubble migration approach is "big bang" — rebuild the entire app in parallel, then switch everything at once on cutover weekend. This works for simple apps, but for complex applications with 20+ data types, multiple integrations, and thousands of active users, the big bang carries enormous risk. One missed workflow, one broken integration, one data migration error, and your cutover weekend becomes a rollback emergency.

The strangler fig pattern — named after the tropical fig that gradually grows around and replaces its host tree — offers an alternative. Instead of rebuilding everything and switching at once, you replace components one at a time. The backend API moves first. Then individual frontend pages. Then the data layer. At each step, the app continues running. Users never experience downtime. And if something goes wrong, you roll back one component, not the entire system.

What Is the Strangler Fig Pattern?

The strangler fig pattern comes from Martin Fowler's writing on legacy system migration. The principle: instead of replacing a legacy system all at once, you build new components alongside it, route traffic to the new components incrementally, and eventually decommission the legacy system when all traffic has been migrated. The legacy system is never turned off in one dramatic moment — it is gradually replaced until nothing depends on it.

Applied to Bubble

In a Bubble context, the strangler fig works like this: set up a proxy (Cloudflare Workers, Nginx, or Vercel rewrites) in front of your Bubble app. The proxy initially routes 100 percent of traffic to Bubble. As you build new components in custom code, update the proxy to route specific paths to the new system. Over weeks or months, more paths route to custom code and fewer to Bubble. Eventually, Bubble handles zero traffic and can be decommissioned.

Why Gradual Migration Reduces Risk

[Table 1] Big Bang vs. Gradual Migration Risk Comparison

Risk Factor	Big Bang	Gradual (Strangler Fig)
Downtime risk	High (cutover window)	Zero (always running)
Rollback scope	Entire system	Single component
Testing in production	First time at cutover	Each component tested independently
Team stress	Extreme (cutover weekend)	Moderate (continuous delivery)
User impact	All users at once	Gradual, can use feature flags
Timeline flexibility	Fixed deadline	Flexible, can pause between phases

The Cash Flow Advantage

Big bang migration requires paying for both Bubble and custom code development for the entire project duration — 3 to 5 months of double spending before any return. Gradual migration produces value incrementally: each migrated component reduces Bubble dependency and can deliver immediate performance improvements. For bootstrapped or cash-constrained teams, this makes migration financially feasible.

Phase 1: Backend API Extraction

Start with the backend — it is the lowest-risk first step because users do not interact with it directly.

What Moves First

Build your new API endpoints alongside Bubble. Start with read-heavy, non-critical endpoints: data retrieval for reports, search functionality, or analytics queries. These endpoints can query a synced copy of your data in PostgreSQL while Bubble remains the source of truth for writes.

Data Synchronization

During Phase 1, Bubble is the write master and your new database is a read replica. Set up synchronization: Bubble workflows push data changes to your PostgreSQL database via API calls. Your new API endpoints read from PostgreSQL. This dual-write pattern lets you validate that your new API returns the same data as Bubble without risking data loss.

Proxy Routing

Configure your proxy to route API calls to the new backend. Start with one endpoint, verify parity, then add more. At any point, reverting a route back to Bubble is a single proxy configuration change — no code deployment needed.

Phase 2: Frontend Component Replacement

Once the backend API is stable, start replacing Bubble frontend pages with React/Next.js pages.

Page-by-Page Migration

Replace one page at a time. Start with the page that has the most SEO value or the most performance problems. The proxy routes that specific path to your Next.js app. All other paths still go to Bubble. Users on the migrated page get the new experience. Users on other pages continue using Bubble. No one notices the transition.

Shared Authentication

The hardest part of gradual frontend migration is authentication. Users must be logged in to both systems seamlessly. Options: shared JWT tokens (your new system and Bubble accept the same token format), session proxy (the proxy adds authentication headers based on a shared session store), or SSO (both systems delegate auth to a shared provider like Auth0 or Supabase Auth).

Phase 3: Data Migration and Cutover

The final phase: switch the source of truth from Bubble to your new database.

Reverse the Write Master

Once all API endpoints and frontend pages are migrated, reverse the data flow: your new system becomes the write master and Bubble becomes the read-only archive. Stop sync from Bubble to PostgreSQL. Start sync from PostgreSQL to Bubble (if needed for remaining Bubble pages). When all traffic routes to the new system, Bubble can be decommissioned.

The Final Cutover

The final cutover in a gradual migration is anticlimactic — which is the point. By this stage, Bubble handles zero traffic. Decommissioning means removing the proxy routes to Bubble and downgrading the Bubble plan. No user-facing change. No downtime. No cutover weekend drama.

Proxy Routing and Shared Authentication

[Table 2] Proxy Options for Gradual Migration

Proxy Solution	Best For	Complexity	Cost
Cloudflare Workers	Path-based routing with edge logic	Low	Free tier available
Vercel Rewrites	Next.js apps with simple routing	Low	Included in Vercel plan
Nginx reverse proxy	Self-hosted with full control	Medium	Server cost only
AWS ALB + path rules	AWS-hosted infrastructure	Medium	$20–$50/mo

Frequently Asked Questions

Migrate Gradually, Launch Continuously

1. The strangler fig pattern eliminates cutover risk: Instead of a single high-stakes weekend, migrate one component at a time with zero downtime. Each component is independently tested, deployed, and rollbackable.
2. Three phases: backend, frontend, data: Extract backend APIs first (lowest risk), replace frontend pages second (one at a time via proxy), and cut over data last (when all traffic routes to the new system).
3. Proxy routing is the enabler: A proxy (Cloudflare Workers, Vercel rewrites, Nginx) sits in front of both systems and routes each path to the appropriate backend. Route changes are configuration, not deployment.
4. Pausability is the killer feature: Gradual migration can pause at any phase boundary. The app runs in hybrid mode until you resume. For cash-constrained or resource-limited teams, this flexibility is invaluable.
5. Architecture documentation defines phase boundaries: Understanding which components depend on which data types and integrations determines how you split the migration into phases. Document first, phase second, migrate third.

Not every migration needs a dramatic cutover. For complex apps with active users and revenue at stake, the strangler fig pattern replaces the big bang with a controlled transition — gradual, reversible, and always live.