The Big-Bang Migration Myth: Strangle the Monolith Instead
Author: WebGoodPeople
The migration from a monolith to a modern stack lives in most CTOs' heads like this: the team goes off on a 12-18 month "big rewrite", ends with one large release, and everything runs on the new system. In reality this model fails in 40-60% of cases. Not because the teams are bad, but because the model itself is bad.
The alternative is the strangler fig pattern: gradually wrapping the old system in the new one, with no "big release". This article covers why big-bang fails, how the strangler fig works, and what a real migration plan looks like when it's split into six-month stages, each of which delivers value on its own.
Why big-bang fails
Three main reasons we see regularly:
1. Requirements drift
The team starts writing against the current state of the business. Over 12-18 months the business changes. By launch, the team finds it has rewritten things that are already obsolete.
Example: a team rewrote a catalog in 2023. When they finished in 2024, it turned out half the categories had been merged, the pricing rules had changed, and the SEO structure needed reworking. A rewrite of the rewrite.
2. The monolith's hidden complexity
A monolith holds 100-200 edge cases that nobody documented. Promo codes with rules, segment discounts, exceptions for partner accounts, legacy clients on special prices. All of it works in the current code, but nobody knows how.
The team rewrites "the main stuff", and at launch it turns out 50 scenarios nobody knew about have broken. The next six months go to "re-implementing what already worked".
3. Big-bang is a high-risk decision for the business
Even when everything is technically ready, switching 100% of traffic to the new system overnight is a decision the CFO or CEO won't take. It gets postponed. The team waits. The new site ages before it ever ships.
Strangler fig: the idea
The name comes from a tree. A strangler fig grows around its host, eventually replacing it, without ever cutting the host down. In software: the new system grows around the old one, handling more and more, until the old one is redundant. The old system is never "cut". It simply becomes vestigial.
Applied to e-commerce:
Start: the monolithic Bitrix handles everything.
Month 3: the Next.js front-end serves catalog pages. Bitrix serves everything else.
Month 6: Next.js serves catalog, product page, and cart. Bitrix handles admin, checkout, and billing.
Month 9: Next.js serves the entire public side. Bitrix handles admin and workflow only.
Month 12+: you can swap Bitrix for any more convenient admin, or keep it, since it no longer matters.
The key point: at every month, Bitrix runs, Next.js runs, and users see no difference. New features land on Next.js. The old functionality migrates gradually. No "big releases".
The 6-stage strangler fig migration plan
Stage 1. API layer and the first page (months 1-2)
- Put an API between Bitrix and the clients
- Move one page to Next.js, usually the category page as the one that earns the most
- Canary → 5% → 50% → 100% of this page over 2 weeks
Value of this stage: on this one page, TTFB drops from 900 ms to 300 ms. Conversion rises by 3-5%. That alone pays back the first 2 months of work.
Stage 2. Product detail page (month 3)
- Add the product page on Next.js
- Integrate with the cart (the cart still lives on Bitrix, via iframe or fetch)
- Canary → 100% over 1 week
Value: the product page's TTFB drops. Time to interactive drops. Conversion from product page to "add to cart" rises.
Stage 3. Search and filters (month 4)
- Connect Elasticsearch directly to Next.js
- Replace the old search and filters with the new ones
- Run an A/B test via interleaving to measure the difference
Value: zero-result rate from 22% to 2%. Conversion through search up 30-60%.
Stage 4. Cart and checkout (months 5-6)
The riskiest stage. This is where users actually enter payment data.
- Run the new cart in parallel with the old one
- Canary 1% → 5% → 20% with dual analytics
- Reconcile financial metrics (payment success, lost orders) in real time
- Ramp up slower than usual: 2 weeks per step
Value: a faster checkout means a higher completion rate. By our data, +10-20% to completion after the migration.
Stage 5. Personal account and history (months 7-8)
- Personal account, order history, favorites, all on Next.js
- Integrate with Bitrix as the history store
Value: faster account pages mean returning users engage more.
Stage 6. Admin, or keep it (month 9+)
Here's the fork. Two options:
Option A: keep Bitrix as the admin. Managers keep working in the familiar back office. The Next.js front-end reads data through the API. Nobody retrains. The migration is done: publicly the site runs on Next.js, internally the admin is Bitrix.
Option B: replace the admin with a headless CMS (Strapi, Sanity, Directus, Payload). This requires retraining managers. Do it only when there's a strong business case (the current admin genuinely slows processes down).
80% of our clients pick Option A. Bitrix is a good admin, just a bad front-end.
Why this approach works
Value at every stage. You don't wait 18 months; first results come in 2. ROI is continuous.
Risk is bounded by the stage's scope. If stage 4 fails, it's a problem with one stage, not the whole project. The rest keep working.
Requirements don't drift. Each stage is short, so requirements don't have time to change.
You can stop. After any stage you can say "this is enough for us" and skip the next ones. You still have an improved site.
Managers adapt gradually. Processes in the admin don't break all at once.
When big-bang is justified after all
Rare cases where staged decomposition isn't possible:
- A database stack change. Moving from MSSQL to PostgreSQL is, by necessity, a one-shot move. But that's a data migration, not a front-end migration, a different task.
- A full business-model change. If you're shifting from retail to a marketplace, the logic is different and there's a lot to rewrite. But even that you can do in parallel with the current site.
- A forced EOL. If Bitrix 16 goes out of support and you need to be on Bitrix 18 within 3 months, that's a forced migration. But even that rarely needs a full rewrite.
In 90% of cases the strangler fig is the right choice.
What to do right now
If "rewrite everything" is on your roadmap, ask three questions:
- Can you start with one page? Usually yes.
- Does that one page deliver value on its own? If it's the category page, almost always yes.
- Can you let the old and new coexist through an API layer? Almost always yes.
Three yeses mean the strangler fig fits you. You don't need a big-bang.
If you're not sure, a 48-hour audit answers exactly these questions. We hand back a concrete plan for the first stage, with an estimate of hours, risks, and expected value.