The big-bang cutover from Magento 1 to Adobe Commerce is the migration pattern most teams plan and most experienced operators avoid. The risk concentrates entirely at a single moment in time. Either the new storefront works on launch day or you spend the next 48 hours rolling back, explaining what happened to the executive team, and rebuilding customer trust. There is no soft landing.
The alternative is a parallel cutover, where both storefronts run simultaneously for a defined window and traffic is shifted gradually from the old to the new. The mechanics are more complex. The risk profile is meaningfully lower. For any storefront doing more than 10 million dollars in annual revenue, the parallel approach is almost always the right call, and the complexity is worth it.
Bemeir’s Adobe Commerce engineering practice has run parallel cutovers on a range of stores. The framework below is how we structure them, what we monitor, and where the operational discipline has to land for the parallel approach to actually reduce risk rather than just spread it across more days.
Why parallel makes sense
A parallel cutover gives you three things a big-bang cutover does not.
The first is a real production validation environment. The new Adobe Commerce storefront sees real customer traffic, real catalog data, real promotions, real edge cases. You cannot manufacture this in staging no matter how good your test plan is. The patterns of failure that surface under real traffic are different in kind from the patterns that surface under synthetic load.
The second is a rollback option that does not require panic. If something goes wrong on day three of a parallel cutover, you reduce traffic to the new storefront and the old one absorbs the load. The recovery is operational and surgical, not strategic. This single fact reduces the political pressure on the engineering team enormously, which means they make better decisions under stress.
The third is a measured comparison of business performance. You can directly compare conversion rate, average order value, abandonment, search behavior, and operational error rates between the old and new storefronts on the same customer base. The data tells you what is actually working on the new platform and what needs another pass before the old storefront is retired.
The trade-off is operational complexity and engineering load during the cutover window. Both stores need to be kept honest. Catalog changes need to propagate. Customer accounts need to be unified. Orders placed on either store need to flow correctly to fulfillment. We will work through each of these.
The reference architecture
A parallel cutover puts a traffic router in front of both storefronts. The router can be a load balancer with weighted routing, a CDN with rules-based routing, or a custom edge service. Cloudflare Workers, AWS CloudFront with Lambda@Edge, and Fastly’s VCL all support the routing logic comfortably. The router decides which storefront serves each request based on a combination of customer cohort, geography, traffic percentage, and feature flag.
Behind the router, both storefronts have full access to the catalog, the customer database, the order management system, and the fulfillment integrations. The catalog and customer data are kept in sync via a bidirectional pipeline. Orders placed on either storefront flow to a single order management system, which is the source of truth for fulfillment.
The diagram in your head should have the traffic router at the top, both storefronts in the middle, a sync pipeline between them, and a single OMS at the bottom. The OMS is the integration backbone. The sync pipeline is the data backbone. The router is the experiment surface.
Data sync between the two stores
The data sync is the technical hardest part of the parallel cutover. It is also the part that determines whether the parallel approach reduces risk or just hides it.
Three categories of data need synchronization. Catalog data, including products, categories, prices, inventory, and promotions. Customer data, including new account creation, address book changes, password resets, and consent updates. Order data, including new orders for assignment to the OMS and order status updates that flow back to both storefronts.
The sync needs to be bidirectional for the catalog and customer data and unidirectional for orders, which only flow out of the storefronts into the OMS. The sync needs to be near-real-time. A 15-minute delay on inventory updates means oversells. A 30-minute delay on price changes means customers can see inconsistent pricing depending on which storefront the router sent them to.
The implementation pattern that works most cleanly is an event-driven middleware layer. Both storefronts emit events to a message queue. A consumer reads the events and writes them to the other storefront. The queue gives you retry on failure, observability into what is in flight, and a buffer if either storefront is briefly unavailable. RabbitMQ, AWS SQS, and Apache Kafka all work for this. Magento 1’s event system can fire webhooks to the middleware on every relevant event with a small custom module. Adobe Commerce’s message broker handles the same on the new side natively.
The Adobe Commerce message queue documentation covers the patterns. The middleware itself is usually a small Node or Go service that the agency builds for the cutover and retires when the parallel period ends.
Routing the traffic
The router is where the cutover plan actually executes. You start with 100 percent traffic on Magento 1 and 0 percent on Adobe Commerce, and you shift over weeks.
A reasonable schedule looks like this. Week one routes 5 percent of new sessions to Adobe Commerce, with the cohort selected by a hash of the session cookie so the same customer returns to the same storefront. Week two raises to 15 percent. Week three to 30 percent. Week four to 50 percent. Week five to 75 percent. Week six to 100 percent. Week seven and eight run on Adobe Commerce alone with the old storefront kept warm but receiving no traffic. Week nine retires Magento 1.
The exact percentages can adjust based on what the data shows. If something is wrong on the new storefront, you do not advance the percentage that week. You investigate, fix, and resume. If everything looks good, you can compress the schedule. The point is that the schedule is conditional on observed health, not on a calendar deadline.
The table below is the cohort scheduling cadence we typically recommend, with the explicit kill criteria for each stage.
| Week | Adobe Commerce traffic | Kill criteria (rollback if observed) |
|---|---|---|
| 1 | 5% | Conversion rate drop >10%, or 5xx rate >0.5% |
| 2 | 15% | Conversion rate drop >7%, or 5xx rate >0.3% |
| 3 | 30% | Conversion rate drop >5%, or 5xx rate >0.2% |
| 4 | 50% | Conversion rate drop >5%, or 5xx rate >0.2% |
| 5 | 75% | Conversion rate drop >3%, or 5xx rate >0.1% |
| 6 | 100% | Stable for at least seven days |
The kill criteria need to be precise and pre-agreed. The engineering team, the marketing team, and the executive sponsor should all know exactly what triggers a rollback and what triggers an investigation versus a full stop. Ambiguity during a cutover produces slow decisions, which is the worst outcome under stress.
What to monitor
The monitoring stack during a parallel cutover is more elaborate than normal operations. You are watching both stores, the sync pipeline, the router, and the business KPIs that the cutover is supposed to preserve.
A working dashboard covers seven monitoring loops. Application errors on both stores, broken out by error class. Application response time on both stores at the 50th, 75th, and 99th percentile. Sync pipeline lag, measured as time from event emission to processing on the other store. Sync pipeline error rate, with errors broken out by entity type. Router behavior, including the actual traffic split and any cohort routing anomalies. Conversion rate on each store, on the same traffic mix. Order flow into the OMS, broken out by store of origin.
This dashboard runs continuously throughout the parallel window. The on-call engineer reviews it at least twice a day. The executive sponsor sees a daily summary. The Datadog runbook automation guide and the New Relic alerting best practices cover the implementation patterns regardless of which observability platform you choose.
Customer-facing inconsistencies
The single most common customer complaint during a parallel cutover is inconsistency. A customer logs in on the new storefront, sees their order history, places an order. They come back two days later, get routed to the old storefront, see a different order history because the sync was delayed, and email support angry.
Reduce this by routing each customer to the same storefront consistently within a session and ideally within a 30-day window. The router decides the assignment once and remembers it. The cookie or the customer database tracks the assignment. Customers who are explicitly assigned to Adobe Commerce stay there for the rest of the parallel period.
The second source of inconsistency is search. The two storefronts may use different search backends, which means the results differ even on identical queries. Either accept this as a known limitation of the parallel window, or unify the search backend so both storefronts query the same Elasticsearch or OpenSearch index. Bemeir typically takes the unification path for stores where search drives meaningful conversion. The work to unify is one or two engineering sprints, and the consistency it produces is worth it.
The third source of inconsistency is promotions. Adobe Commerce and Magento 1 model price rules slightly differently. A promotion that fires correctly on one storefront may behave subtly differently on the other. Audit every active promotion before the cutover begins and confirm the behavior matches across both storefronts. Discrepancies here produce customer complaints that look like billing issues, which are the most painful kind to deal with.
Cutover completion criteria
A parallel cutover is complete when three conditions are met. The Adobe Commerce storefront has carried 100 percent of traffic for at least 14 consecutive days with conversion rate, AOV, and error rates within target ranges. The sync pipeline has been turned off and any data that was being written to Magento 1 has stopped flowing. The Magento 1 storefront has been gracefully retired, with redirects in place for any URLs that did not survive the migration and customer-facing communications confirming the transition.
After completion, the Magento 1 codebase should be archived in a way that preserves access for legal and tax purposes but does not stay in production. The hosting can be downsized or terminated. The integrations that pointed at Magento 1 can be reconfigured to point at Adobe Commerce. The OMS continues running as the single source of truth.
Most parallel cutovers we run complete in eight to 12 weeks from first traffic shift to retirement. Stores with higher complexity, especially B2B stores with company hierarchies or stores with heavy promotional behavior, take longer. The discipline is the same regardless: shift only as fast as the data lets you, monitor relentlessly, and treat every customer complaint as a signal about the next decision rather than an inconvenience.
If you are running the same migration analysis against Shopify Plus or Shopware as alternatives to Adobe Commerce, the parallel cutover pattern translates. The platform-specific integrations differ. The data sync architecture differs in detail. The traffic routing logic is portable. The kill criteria and the monitoring discipline are the same. The pattern is durable because it is about risk management, not about platform mechanics.
The parallel approach is the way mature engineering teams run high-stakes platform transitions in 2026. Big-bang cutovers still happen, mostly on small stores or under deadline pressure that does not allow the longer window. For everyone else, the operational complexity of running two stores in parallel for a quarter is much cheaper than the operational cost of a failed launch. Plan for parallel, even if you end up not using it. The plan itself produces better decisions about the migration.
