What is big bang migration
Big bang migration is the approach where you stop all development on the current platform, rewrite everything from scratch on the new one, and flip traffic in a single cutover event. It sounds like a clean slate. In practice it means 6–18 months of parallel development, a frozen main site, and enormous risk at the moment of launch.
In the context of 1C-Bitrix e-commerce, big bang looks like this: "Let's migrate the whole store to Next.js, rewrite the backend, port the 1C integrations, and launch everything in 4 months." The "everything at once" part is what kills projects.
Why it seems like the right call
Big bang is appealing for several reasons, each of which makes sense in isolation:
- The clean slate illusion. Old code has accumulated technical debt and everyone wants to start without workarounds. This is real pain — but the answer is refactoring, not a full rewrite.
- "It's cheaper to do it all at once." Maintaining two sites in parallel seems more expensive. In reality big bang projects routinely come in at 2–3× the original estimate.
- "The platforms are incompatible." If Next.js and Bitrix are so different, how do you connect them? API integration is exactly the co-existence model that works for years.
- "The transition period confuses the team." Two sites, two codebases, two deploys. But that discomfort lasts 6–8 weeks, not 6–18 months of high risk.
6 reasons it fails
1. Requirements change faster than you write code
Over 4–6 months of building from scratch, the business changes direction at least twice. When you finally launch, part of what you built is no longer needed and part of what is critical was never built. An incremental approach lets you course-correct every 2–4 weeks.
2. SEO collapse at cutover
Simultaneous changes to platform, URL structure, metadata, and site speed create a "new domain" effect for search engines. Yandex and Google need time to re-index. The typical picture after big bang: −30–50% organic traffic for 3–6 months. With incremental migration, search engines see gradual improvement — no shock.
3. Integrations break at the worst possible moment
1C exchange, payment processors, delivery providers, marketplaces, BI, ESP, logistics — every integration has edge cases that only surface under real load. With big bang they all fire simultaneously on launch day, when there is no bandwidth to investigate calmly.
4. No rollback path
Once everything has switched at once, rollback means re-migrating in reverse. In practice this is impossible: order data is already flowing into the new system, the old one is already stale. With incremental migration, rollback is one CI command and takes 15 minutes.
5. Team burnout over the long haul
6–12 months without shipping features to production, without user feedback, without visible progress — developers lose motivation. The best engineers leave before launch. Incremental migration gives the team a "win" every 2–4 weeks.
6. Budget runs out before the project does
McKinsey data shows large IT projects overrun budget by an average of 45%. For big bang migrations the figure is higher — because of unexpected integration work, approval delays, and rework. The cost of "just one more sprint" accumulates invisibly.
The real cost of "rewrite everything"
For a 10,000-SKU store with a typical integration stack, big bang migration usually means:
- Development timeline: 6–12 months (vs. 2–4 weeks for a pilot)
- Budget: 3–5× higher than the incremental route
- Lost revenue: no storefront optimizations during the entire period
- SEO risk: −30–50% organic traffic for a quarter on a bad launch
- Team risk: loss of 1–2 key engineers before go-live
The alternative: strangler fig and incremental migration
The "strangler fig" pattern was described by Martin Fowler in 2004: a new system gradually wraps around the old one, intercepting traffic piece by piece until the old system withers away. In e-commerce this looks like:
- Start with one category — the simplest or highest-traffic one. Launch the headless storefront there.
- The old site keeps running — sales do not drop, the team does not panic, search engines do not notice a disruption.
- Gradually shift traffic — 5% → 30% → 80% → 100%, with metrics reviewed at each step.
- Rollback is one CI command — if anything goes wrong, it takes 15 minutes, not weeks.
- Backend stays intact — 1C, Bitrix, CRM, ERP keep running. The migration only touches the storefront.
How it works in practice
Our migration approach is built on the strangler fig principle, adapted for the 1C-Bitrix ecosystem:
- Days 1–3: Catalog Probe. You upload a CSV/XML — in 3 days you have a live headless preview with your catalog. You see speed metrics before any commitment. Backend untouched.
- Weeks 2–4: Pilot on one category. One catalog section in production on the headless front. Measurable results: LCP, conversion, search response. If KPIs are not met — pilot at no charge.
- Weeks 5–12: Gradual cutover. A/B test with increasing headless traffic share. Rollback available at any point.
- Months 2–4: Full replatform. 100% traffic on headless, old Bitrix front switched off. Backend — unchanged.
When big bang is actually justified
Honest answer: rarely, but it happens. Big bang may be the right choice when:
- The current platform is technically incompatible with API integration (exotic legacy with no REST/SOAP surface).
- The business model is changing fundamentally — not just a new front end, but a new data model, new processes, new order logic.
- The store is small (under 500 SKUs, a single category) and risk is minimal.
- There is a hard external deadline (new market entry, franchise launch) where incremental migration does not fit the timeline.
Even in these cases we recommend a Catalog Probe first — to understand the scope and establish baseline metrics.
Frequently asked questions
Can you avoid big bang if the platform is old and has no proper API?
Usually yes. Even older versions of 1C-Bitrix expose a REST API or support catalog export via XML/CSV. Catalog Probe works with exactly that format. If there is genuinely no API — that is one of the rare cases where big bang or a partial big bang may be justified. We check this at the zero stage, before any commitment.
What happens to SEO with incremental migration?
You switch one category at a time. URL structure is preserved, 301 redirects are set up per page, metadata is ported. Search engines see a speed improvement on one section — not a "new domain" all at once. Typical result: Core Web Vitals go up on migrated pages with no drop on the rest.
How much does incremental migration actually cost?
Catalog Probe is a fixed-cost, three-day engagement. A Pilot on one category takes 2–4 weeks. Full cutover takes 2–4 months. Total cost depends on the number of integrations and catalog size, but runs 3–5× lower than big bang — where unforeseen integration work eats through the budget continuously.
What if the team can't manage two live sites at once?
Running two front ends in parallel lasts 6–8 weeks for most projects — not "two sites forever." After cutover the old front end is switched off. A team that cannot handle 6 weeks of parallel mode is probably not ready for 12 months of big bang risk either.
We've already started a big bang migration. What now?
If less than 2–3 months have passed, switching to an incremental approach is usually doable. Some of the new codebase is already built and can serve as the Pilot foundation. Beyond that we assess the situation individually. We have made this kind of pivot before — the key question is which integrations are already working in the new system.
Does a headless storefront have to be Next.js?
No. Strangler fig works with any front end that can accept traffic via reverse proxy. We use Next.js because it delivers the best Core Web Vitals out of the box and we have built up Bitrix-specific templates over time. But the "one category first, then gradual cutover" principle is not tied to any particular stack.
What if we want to switch front ends again in a year?
That is exactly why we leave the backend untouched. 1C-Bitrix, 1C, and all integrations stay in place. A new front end connects via the same API. Switching takes 2–4 weeks — not a new big bang.
Are there companies where big bang actually worked?
Yes, and we say so directly in the "When big bang is actually justified" section. Small stores under 500 SKUs, fundamental business model changes, or legacy platforms with no API at all — these are real cases. The failure statistics apply to mid-size and large projects with a live, revenue-generating site.
Checklist: how to choose your approach
- ☐ Site generates revenue every day — consider incremental migration
- ☐ You have SEO traffic — incremental preserves it, big bang risks losing it
- ☐ Backend is stable and has a REST API — ideal for strangler fig
- ☐ Team wants to see results fast — Catalog Probe delivers in 3 days
- ☐ Not willing to maintain two sites for more than 3 months — accelerate cutover
- ☐ Budget is fixed — incremental is predictable, big bang is not