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

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. Catalog Probe (3 days)

Upload a CSV/XML of your catalog to the Frontbox demo stack. In 3 days you get a link to a live Next.js preview of your store with your products, prices and images.

Deliverable: preview domain, screenshots, LCP/TTFB/INP measurement, a list of catalog issues (duplicate SKUs, broken images, missing attributes).

Why: in ~30% of cases discovery ends here — the team realises that data needs to be cleaned first, not migrated.

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.

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.

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.

Final checklist

• ☐ Catalog Probe shipped, 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.