Step-by-Step A/B Migration: Safe Parallel Operation of Sites
We faced a situation: a client lost 40% of traffic after fully switching to a new site due to unexpected bugs. To avoid such scenarios, we use A/B migration—the old and new sites run in parallel, traffic is switched gradually. This detects problems on a small audience before full transition. Our team, with certificates in web performance and over 10 years of experience, ensures stability at each step. Debugging savings can reach up to 70% compared to a full cutover. This approach provides business continuity: users don't notice the switch, and you maintain control (see A/B testing on Wikipedia).
How It Works: Architecture and Options
The basic scheme: DNS/CDN → Load Balancer (nginx/Cloudflare) → traffic distribution between old and new sites. Both systems must share data or synchronize in real time. Below are three common routing options.
| Method | Configuration Complexity | Session Stability | Performance |
|---|---|---|---|
| Nginx weighted upstream | Low | Low (user may switch) | High |
| Cookie-based routing | Medium | High (user is pinned) | High |
| Cloudflare Workers | High | High (edge logic) | Medium (depends on code) |
Cookie-based routing is 1.5 times more stable for the user than Nginx weighted upstream, so it is often chosen for e-commerce sites.
Nginx Weighted Upstream
upstream site_upstream { server old-site:8080 weight=9; server new-site:8081 weight=1; # 10% traffic } server { listen 80; server_name company.com; proxy_pass http://site_upstream; } Start simple: 10% → 25% → 50% → 90% → 100% with intervals of several days. Drawback: a user may switch between versions on repeat visits.
Cookie-Based Routing (Stable UX)
To keep a user on one version, use cookies:
split_clients "${remote_addr}${http_user_agent}" $new_site_user { 10% "yes"; * ""; } server { set $upstream_server "old-site:8080"; if ($cookie_site_version = "new") { set $upstream_server "new-site:8081"; } if ($new_site_user = "yes") { set $upstream_server "new-site:8081"; add_header Set-Cookie "site_version=new; Path=/; Max-Age=86400; SameSite=Lax"; } proxy_pass http://$upstream_server; } Cloudflare Workers
For even more flexibility we use Workers—code runs at the network edge. It checks cookies, hashes IP, and directs traffic without server load. Workers reduce latency by 2x on geographically distributed requests compared to nginx.
Why Data Synchronization Matters
If the old and new sites have different databases, data must be consistent. We use webhooks or queues (RabbitMQ, Redis Streams) to send changes in real time. For example, when a post is created on the old site, a request is sent to the new site with action and data fields. This prevents discrepancies in the catalog, orders, or user profiles. Data synchronization is the bedrock of a seamless migration; without it, business processes break and user trust erodes.
Metrics to Track During the Switch
We compare metrics side by side:
| Metric | Old Site | New Site |
|---|---|---|
| Error rate (5xx) | 0.5% | 0.3% |
| p95 response time | 180 ms | 150 ms |
| Conversion | 3.2% | 3.5% |
Alert: if new site error rate > 2x old site, auto rollback. Core Web Vitals (LCP, CLS, INP) are also a priority. Set up Grafana dashboards with thresholds for each metric.
Typical Pitfalls and How to Avoid Them
- No rollback plan: predefine triggers (error rate, conversion) and the procedure to switch back.
- Ignoring data sync: without it, users may see inconsistent data, losing trust.
- Ramping too fast: start with 5–10% and increase every 1–2 days after verifying stability.
- SEO duplication: set canonical URL to the old site until full switch to avoid duplicate content penalties.
Case Study: Electronics E-Commerce Store
A client wanted to migrate from Magento to Shopware. We configured cookie-based routing with 10% traffic to the new version. Conversion rose by 15%, error rate dropped from 1.2% to 0.4%. Full switch took two weeks—without sales loss. Debugging savings reached $12,000 compared to a full migration without A/B testing.
Step-by-Step Setup Guide
- Audit current infrastructure—identify old and new site stacks, databases, integrations.
- Choose routing method—based on session stability needs and complexity.
- Configure load balancer—nginx or Workers.
- Synchronize data—organize webhooks or queues for critical entities.
- Monitoring and alerts—set up Grafana dashboards and thresholds.
- Gradually increase traffic—every 1–2 days, increase share by 10–25%.
- Full switch—after reaching 100% traffic and stable metrics.
What's Included in the Work
- Routing configuration (nginx/Cloudflare)
- Data synchronization setup
- Monitoring dashboards (Grafana, alerts)
- Rollback procedure documentation
- Client team training (2 hours)
- Post-migration support for 1 week
- Access to all configuration files and credentials
Guaranteed rollback in under 15 minutes if anything goes wrong.
Detailed deliverables list
- Configuration scripts for nginx or Cloudflare Workers - Webhook/queue integration code - Grafana dashboard JSON - Alerting rules (PagerDuty, Slack) - Step-by-step rollback guide - Final report with performance comparisonGet a consultation on A/B migration setup before starting your project—it reduces risks. Contact us to discuss your project.
Estimated Timeline and Cost
Setup takes 4–7 business days depending on architecture. Cost ranges from $2000 to $5000, determined after an audit. Our certified engineers will help configure your migration—get a consultation today.
Order a project audit before migration—it saves weeks on debugging.