Strangler Fig: Monolith to Headless, No Downtime

The problem: fear of migration is rational

Most failure stories in enterprise development share one root cause: someone tried to rewrite everything at once.

A big-bang migration, where the team freezes feature work, plans a full move, migrates all the data, and cuts over on a fixed date, maximizes several risks at the same time:

• Business risk: if something breaks, the whole business takes the hit.
• Schedule risk: a full rewrite almost always runs longer than planned.
• Data risk: moving the catalog, orders, and content all at once makes errors likely.
• SLA risk: long migration windows create downtime risk.

The result: teams either postpone forever ("we'll migrate when we're ready") or launch the migration and hit a painful rollback.

The cost of inaction

But not migrating has its own cost:

• Frontend and backend stay coupled, so every UI change needs backend work.
• Release speed is capped by the slowest component.
• Technical debt grows with every patch layered on top of the monolith.
• Hiring for a legacy stack gets harder every year.

The question isn't "migrate or not." The question is "how do we migrate without putting the business at risk?"

The approach: the Strangler Fig pattern

The pattern is named after the tropical plant that slowly wraps around a host tree. The new system grows around the old one, traffic shifts over gradually, and the monolith dies off naturally as each component migrates.

The core principle: we don't replace the monolith. We build a route around it, one user journey at a time.

The mechanism: phase by phase

Phase 0: Preparation

• Audit the current user journeys and their backend dependencies.
• Define the API contract for the first journey to migrate: what data is needed, and in what format.
• Baseline metrics: page speed, error rate, conversion for the target journey.

Phase 1: First journey behind an API boundary

• Pick a journey with high value and low coupling (usually a category listing or search).
• Build a new implementation on Next.js that consumes data through an API adapter.
• The API adapter translates between the new frontend and the existing backend (Bitrix or another).
• Users don't see any of this. It runs in parallel.

Phase 2: Traffic routing

• Route a small share of traffic (say 5-10%) to the new implementation.
• Monitor latency, error rate, user behavior, and conversion.
• Compare against the baseline.
• Roll back if anything is unexpected. It's one command in the deploy pipeline.

Phase 3: Gradual scale-up

• Increase the traffic share as confidence grows: 25% to 50% to 100%.
• At 100%, the old implementation of this journey no longer serves traffic.
• The monolith still exists. It's just been strangled for this one journey.

Phase 4: Repeat

• Next journey: product page, search, cart and checkout, customer account.
• Every migration follows the same pattern.
• The monolith shrinks; the new API-first system grows.

What stays intact throughout

• Revenue: traffic shifts over gradually instead of at a single cutover.
• SLA: rollback is available at every step.
• Existing integrations: the API adapter talks to Bitrix, so CRM, warehouse, and 1C aren't touched in the early phases.
• Team capacity: each phase is a bounded sprint, not an open-ended rewrite.

Limitations (honestly)

• This approach takes longer than a big-bang migration.
• Maintaining the API adapter layer adds engineering overhead during the transition.
• The team needs discipline in versioning API contracts.
• If the monolith's data schema is badly tangled, extracting API contracts requires analysis up front.

Evidence to make the case internally

• A phased roadmap with defined milestones and rollback criteria.
• An architecture blueprint with the API adapter layer and the routing mechanism.
• Baseline and target metrics for each phase (not "it'll get better," but "here's what we measure").

Next step

If you're preparing an architecture decision or you need a migration roadmap to present to your tech council, we offer a free one-hour architecture review.

We'll go through the current state, decide which journeys to migrate first, and lay out a phased plan with explicit rollback points.

Book an architecture review: webgoodpeople.com/en/contact

See the product: Headless Next.js + Elasticsearch