Why Big Bang Migration Is a Mistake

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:

1. Start with one category — the simplest or highest-traffic one. Launch the headless storefront there.
2. The old site keeps running — sales do not drop, the team does not panic, search engines do not notice a disruption.
3. Gradually shift traffic — 5% → 30% → 80% → 100%, with metrics reviewed at each step.
4. Rollback is one CI command — if anything goes wrong, it takes 15 minutes, not weeks.
5. Backend stays intact — 1C, Bitrix, CRM, ERP keep running. The migration only touches the storefront.

How to protect budget without fake fixed-price certainty

In a migration, replatform, or non-standard integration project, asking a vendor for a fixed price before discovery is risky. That number usually hides unknowns: integrations, roles, 1C exchange, catalog rules, SEO structure, acceptance criteria, and data issues that only become visible after system access.

A better frame is not "the exact price for everything." It is a compact decision structure: what belongs in the base pilot, what is optional, which client-specific scenarios need separate estimation, and which metrics prove that continuing is sensible.

• Start with preliminary requirements. A short document that the owner, CTO, and e-commerce lead can review and correct in one meeting is enough.
• Then ship one measurable slice. One category, one search scenario, or one API contour shows delivery speed, review quality, and transparent Git Flow.
• Only then estimate by scope. Cost depends on integrations, data, roles, workflows, and acceptance criteria — not on a neat promise in the first call.

How it works in practice

Our migration approach is built on the strangler fig principle, adapted for the 1C-Bitrix ecosystem:

• 48 hours: Audit. We review your site, stack, speed, and catalog for free — and hand back a bottleneck map, base scope, optional blocks and budget drivers. We also show similar cases so the decision is concrete. Backend untouched; the exact estimate depends on integrations, data, roles and acceptance criteria.
• 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.

What decision makers get before a large budget

The value of the audit is not a rushed quote. It is clarity for the owner, CTO, or e-commerce lead: what truly needs to change, what can stay inside the current Bitrix contour, and where measurable risk sits. The output should work in a decision meeting, not only inside the development team.

• Constraint map: speed, catalog, search, SEO, integrations, checkout, 1C exchange, and areas that should not be touched without a rollback plan.
• Scope structure: base pilot, optional blocks, and client-specific scenarios separated so the budget does not absorb every hypothesis.
• Acceptance criteria: which before/after metrics matter, where staging is required, and what evidence is enough to continue or stop.
• Next small step: category, slice, or test task that proves delivery speed, workflow quality, and transparent Git Flow.

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 starting with an audit — 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. The audit checks exactly that. 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?

The audit is free, takes 48 hours, and gives you a work structure: base scope, optional blocks, critical integrations and a preliminary estimate. A Pilot on one category takes 2–4 weeks. Full cutover takes 2–4 months. Total cost depends on integrations, catalog size, roles, data and acceptance criteria.

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 — a free audit delivers in 48 hours
• ☐ Not willing to maintain two sites for more than 3 months — accelerate cutover
• ☐ Budget needs control — separate base scope from optional work before estimation