How long does the whole migration process take?

Minimum two months for a store under 5,000 SKUs with standard integrations. Typically three to four months. Main extenders: non-standard integrations and client-side team changes.

Bitrix to Next.js migration: 8 phases, zero downtime

Prep: 3 preconditions

Before starting, check three preconditions. Without them migration turns into "rewrite everything" and eats 9 months.

Backend is stable. If 1C exchange fails weekly and nobody can find the cause — fix that first. Headless on top of chaos is chaos with a pretty UI.
SEO baseline captured. Export top‑1000 keyword rankings and Core Web Vitals before kickoff. Otherwise in 3 months you can't prove migration didn't hurt traffic.
A client‑side product owner exists. Not a CTO, not a CMO — a specific person who decides scope and release timing.

Phase 1. Initial diagnosis

Before the brief, collect the starting context: site, stack, speed, catalog and launch constraints. This separates technical risks from the first work slice without promising scope before the conversation.

Deliverable: LCP/TTFB/INP measurement of the current site, a list of catalog issues (duplicate SKUs, broken images, missing attributes), budget drivers and the next work slice.

Why: sometimes discovery ends here: the team realises that data needs to be cleaned first, not migrated.

Have a migration task? Send a short summary through the form or Telegram. In a 15-minute brief, a product owner and developer will discuss the approach, first work slice and budget drivers. Discuss your task →

What should exist before the first slice

A useful diagnosis does not end with "we can build this". Before the first slice, the owner or CTO should have a compact decision package they can share with a partner, team lead or finance person without translating engineering shorthand.

Base scope. Which screens, APIs, roles, integrations and acceptance criteria are included in the first work slice.
Optional scope. What improves the solution but should not block the hypothesis test: advanced filters, personalisation, extra storefronts, BI events.
Risk map. Where delays can appear: 1C exchange, catalog quality, SEO URLs, payments, access rights, editorial workflow and load.
Budget drivers. Not a fixed quote before discovery, but visible estimate factors: data, integrations, workflows, roles, tests, handoff and SLA.
Continuation criteria. Which metrics show that the first slice is worth extending: LCP, API errors, PDP conversion, SEO visibility and release speed.

Why it matters: this package lowers the risk of an endless migration. The client sees what they are buying in the first slice, what stays optional and why the final estimate depends on real scope instead of a neat landing-page promise.

Phase 2. Discovery and SEO audit (3–5 days)

Audit URL structure: all /catalog/, /product/, /info/.
Collect Core Web Vitals from Google Search Console and Yandex.Metrica.
Integration map: 1C, ЮKassa, Stripe, CDEK, marketplaces, BI, ESP.
Bitrix custom component analysis — what to reuse, what to drop.
Backlog of 20–30 user stories prioritized P0 / P1 / P2.

Phase 3. One‑category validation

Pick one category — usually mid‑traffic so A/B is representative. Full scope: PDP, listing, cart, checkout, payment, delivery.

Key metric:mobile LCP ≤ 2.0s on 4G, PDP conversion not worse than current. If not — don't ship, fix first.

Phase 4. Integration layer (3–6 weeks in parallel)

While the team works on the first slice, we build the data layer for the later migration:

1C exchange: Bitrix webhook → Frontbox queue → Elasticsearch indexing.
Payments: abstract PaymentGateway → Stripe, ЮKassa, Tinkoff, SBP, Kaspi adapters.
Delivery: unified shippingProvider → CDEK, Boxberry, Post, DPD adapters.
Marketplaces: feed generators for WB, Ozon, Kaspi, Yandex Market.
Monitoring: Sentry, Grafana, Telegram alerts on sync failures and SLA breaches.

Phase 5. A/B cutover (4–8 weeks)

Start with 5% of mobile traffic on Frontbox. Every 3–5 days ramp up: 5% → 15% → 30% → 50% → 80% → 100%. Each step comes with metric reconciliation on:

Conversion rate (mobile and desktop separately).
Bounce on PDP and listing.
Core Web Vitals in real‑user sessions.
Checkout and payment error rate.
Rankings on top‑100 SEO queries.

Phase 6. Full replatform (1–2 weeks)

All pages served by Frontbox, old Bitrix frontend decommissioned. Final 301 map for anything changed, ping Google and Yandex with the new sitemap.

Phase 7. Load tests and Black Friday

Before peak events (BFCM, 11.11), run k6 scenarios at 3–5× normal load. Test edge cache, Elasticsearch and Bitrix APIs separately.

Common mistake: testing only the frontend. The bottleneck is always on the Bitrix side — it falls over first at 2× traffic. Set API rate‑limits and add graceful degradation: if the API times out, serve the product from cache with a "price may vary" note.

Phase 8. Handoff and SLA

Frontbox sources (open‑core) in your Git.
Documentation: architecture, API, incident runbook.
CI/CD pipelines in your GitHub / GitLab.
Optional retainer: 20–40 hrs/month, 99.9% SLA with financial penalty.

What to send before the first call

If you already see that the current Bitrix setup slows releases down, you do not need a large specification before the first contact. A short context package is enough to separate technical risk from the commercial hypothesis.

Catalog size and shape: SKUs, categories, filters, how often stock and prices change.
Current symptoms: slow pages, exchange failures, expensive releases, SEO decline, design limits or weak search.
Integrations: 1C, CRM, payments, delivery, marketplaces, BI, email/SMS.
Launch constraints: seasonality, campaigns, downtime limits and required acceptance criteria.

Next step: send this context in Telegram or through the form. We will prepare a compact scope review: what belongs in the first work slice, what stays optional, which data must be checked and what will drive the estimate. Send context →

Rollback procedure

At every cutover step, rollback is one command in CI. The old Bitrix frontend runs in parallel until the metrics are confirmed. If Frontbox performs worse, return 100% of traffic to the old front-end and investigate the cause.

Rollback stops working once you shut down the old Bitrix frontend before metrics are confirmed at 100% traffic. Keep it live until the final sign-off.

Final checklist

☐ Audit completed, metrics captured.
☐ SEO baseline captured (rankings + CWV).
☐ Test category passed A/B, metrics not worse.
☐ Integration layer covered by e2e tests.
☐ 301 map generated and in sitemap.
☐ Load tests at 3× complete.
☐ Rollback procedure rehearsed on staging.
☐ Handoff package assembled and delivered.
☐ SLA signed, penalties active.

FAQ

Does this playbook work if our Bitrix setup is heavily customised?

Usually yes. The playbook is built around API integration, not replacing Bitrix. As long as you have a catalog REST API — even a custom one — the audit works on it. If no API exists at all, we start with Phase 2 Discovery to scope the data extraction work.

Can we validate a category without an initial diagnosis?

Start with the available context and a 15-minute brief instead. That gives the team a chance to check the catalog, integrations and first slice before agreeing on tasks. If the context is incomplete, clarify it first.

What should we do if SEO rankings drop after launching the test category?

Check canonical tags on the test category, URL duplication across old and new fronts, and hreflang correctness. If the drop is material, roll back via CI and review the URL map.

How long does the whole process take, end to end?

Minimum two months for a store under 5,000 SKUs with standard integrations (ЮKassa, CDEK, 1C). Typically three to four months. The main extenders are non-standard integrations and client-side team changes mid-project.

Does Phase 4 need a dedicated team?

Not a separate team, but parallel capacity. One engineer can work on the first-slice UI while another builds the data layer. Working solo means the tasks run sequentially.

What happens to orders during the A/B cutover?

Orders placed on the Frontbox front-end go directly into the Bitrix back-end through the same API. There is one source of truth — no order is lost if you roll back. This is the key difference from big bang.

When is a direct full cutover justified instead of gradual A/B?

Only for small stores: under 500 SKUs, one category, minimal integrations, no significant SEO dependency. Otherwise A/B reduces risk by an order of magnitude. Switching 100% of traffic at once without A/B is essentially big bang with finished code.

How do we make load tests reflect a real peak event?

Pull analytics data for last year's peak day. Look at 15-minute RPS peaks, not daily averages. Multiply by 3×. Test edge cache, Elasticsearch and Bitrix API separately — each has its own bottleneck.

1C‑Bitrix to Next.js migration: 8 phases with zero downtime