webgoodpeople Logo
Contact
Message on Telegram

← All guides

Playbook · 22 min

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

The real sequence we use to migrate stores from 5,000 to 100,000 SKUs. No marketing generalities — checklists, commands and time benchmarks for each phase.

22 min read · Updated: April 2026

Prep: 3 preconditions

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

  1. 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.
  2. 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.
  3. A client‑side product owner exists. Not a CTO, not a CMO — a specific person who decides scope and release timing.

Phase 1. Audit (48 hours)

A free technical audit in 48 hours: we review the site, stack, speed and catalog. The output is a map of bottlenecks, base scope, optional blocks and a preliminary estimate.

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: in ~30% of cases discovery ends here — the team realises that data needs to be cleaned first, not migrated.

Ready to start with an audit? In 48 hours we'll review your site, stack and catalog, separate base scope from optional work and show the budget drivers — plus similar Next.js migration cases. Get a free audit →

What should exist before pilot

A useful audit does not end with "we can build this". Before pilot, 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.
  • Go / no-go criteria. Which metrics prove the pilot is worth scaling: 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 pilot (2–4 weeks)

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 pilot, we build the data layer for the full replatform:

  • 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.

Rollback procedure

At every cutover step, rollback is one command in CI. The old Bitrix frontend runs in parallel for all 6 weeks. If Frontbox performs worse on a metric — 100% of traffic returns within 15 minutes.

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).
  • ☐ Pilot 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 skip the audit and start directly at Phase 3?

You can. But the audit takes 48 hours and shows real speed metrics before any commitment. In roughly 30% of cases it reveals data quality issues that would derail Phase 3. Skipping the audit usually costs more time in Phase 3.

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

Check three things: canonical tags on the pilot category, whether URLs are duplicated across old and new fronts, and hreflang correctness. A drop on one category rarely hits overall traffic significantly. If it's more than 15% for the pilot category over a week — 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 on pilot UI, one on the data layer. Working solo — sequential approach adds roughly three weeks.

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.

What to read next - Related materials