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. 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.
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 — Catalog Probe works on it. If no API exists at all, we start with Phase 2 Discovery to scope the data extraction work.
Can we skip Catalog Probe and start directly at Phase 3?
You can. But Probe costs 3 days and shows real speed metrics before any commitment. In roughly 30% of cases it reveals data quality issues that would derail Phase 3. Skipping Probe 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.