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: depends on integrations, catalog, roles, and acceptance criteria
• 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: which tasks come first, which client-specific scenarios need separate estimation, and which metrics show that the project is moving in the right direction.

• Start with context. The owner, CTO, or e-commerce lead describes the current system, constraints, and desired outcome.
• Then hold a focused brief. A product owner and developer clarify the inputs, possible approach, and budget range.
• Then build a roadmap. The work is split into requests delivered through a subscription or contract arrangement.

How it works in practice

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

• Start with context. If the inputs are sufficient, we review the task and prepare an initial range before the conversation. If not, we clarify the situation first.
• 15-minute brief. A product owner and developer discuss the options, approach, and budget range for the specific project.
• Roadmap. The project is split into ordered requests with clear dependencies and acceptance criteria.
• Request-based delivery. Agreed work is delivered through a subscription or contract arrangement; rewriting the backend is not a mandatory step.

What decision makers get before a large budget

The value of the initial review 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.
• Task structure: first requests, separate scenarios, and dependencies are kept distinct 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 step: after the brief, the team prepares a roadmap and agrees on the first requests.

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, start by discussing the inputs and defining the scope.

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. A brief can clarify which exchange options are available and whether a large transition is necessary. If there is genuinely no API, a full replacement may be justified.

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?

Cost depends on integrations, catalog size, roles, data, and acceptance criteria. After discussing the inputs, the team can give an initial budget range and suggest a roadmap with the first requests.

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 part of the new codebase is already built, it can be assessed as one option for the next stage. The decision depends on integrations, data, and what already works 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 a controlled next step — discuss the task in a 15-minute brief
• ☐ Not willing to maintain two sites for more than 3 months — accelerate cutover
• ☐ Budget needs control — separate base scope from optional work before estimation