A Magento migration can look healthy while live revenue quietly breaks. A checkout can reach the new stack while inventory updates remain on the old database.
An in-flight order can disappear between them. Under campaign traffic, a few seconds of split-brain behavior can cause oversells and duplicate payments.
It can also cause abandoned carts and support tickets after cutover.
A zero-downtime migration for high-traffic Magento stores needs parallel environments and continuous data sync. It also needs compatible database changes, controlled traffic switching, and a tested rollback path.
Prepare the target and ownership map
Build the new environment to match production behavior before moving a single shopper.
Choose the target based on verified peak load, not monthly hosting price. Managed cloud setups on Amazon Web Services, Google Cloud, or Microsoft Azure can spread application nodes across availability zones.
A virtual private server can fit stable traffic, but your team must manage failures directly.
| Target option | Peak-capacity method | Typical migration risk | Best fit |
|---|
| Managed cloud hosting | Add app nodes in minutes | Provider limits on database access | Teams needing managed operations |
| VPS cluster | Manual node additions | One missed service dependency | Stable traffic and strong sysadmin cover |
| Dedicated servers | Fixed hardware capacity | Slow replacement during hardware faults | Predictable large workloads |
| Self-managed Kubernetes | Horizontal pod scaling | Cluster and storage complexity | Teams already operating containers |
Assign one writer per data type
Write a one-page ownership map before the rehearsal. During replication, keep the old production database as the write authority.
Keep it authoritative for orders, customers, inventory reservations, and catalog edits. Maintain this rule until traffic cutover begins.
Confirm security and observability
Install application performance monitoring before the rehearsal. New Relic or Datadog should show PHP errors and database time.
They should also show Redis calls, queue lag, and external API time.
Sync data with compatible schema changes
Create a live data path before copying the application.
Expand first and contract later
Deploy new nullable columns, new tables, and new indexes before cutover. Avoid renaming columns while old application nodes can still write.
Do not drop fields or change data types. Do not make a field mandatory while old nodes might write to it.
bash
bin/magento maintenance:disable
bin/magento setup:upgrade --keep-generated
bin/magento setup:di:compile
bin/magento cache:flush
Copy once, then capture changes
Take an initial database copy during low activity. Then start MySQL replication or change-data capture from binary logs.
Check replication lag every minute. Keep it under 5 seconds during the final switch.
Do not allow any sustained period above 15 seconds.
Control cron jobs and consumers
Create a service worksheet for Magento cron jobs, indexers, RabbitMQ consumers, imports, and custom workers. Mark each job as old only, new only, or safe on both.
Apply each label during every migration phase.
Magento migration flow
Old store
Active writes
→ Replication →
New store
Readiness tests
→ Canary →
Traffic switch
Rollback ready
Keep one write authority until the controlled cutover point.
Database replication alone does not protect live orders. The team must validate Magento entities and side effects that affect commerce operations.
Track incremental changes for sales orders, order items, customer accounts, and catalog updates. Track Magento inventory reservations, quotes, and payment status updates too.
Use database replication, MySQL binary logs, or change-data capture. Do not check only total row counts.
Checkout sync also needs reconciliation by order increment ID and payment transaction ID. Check SKU, source code, and reservation quantity too.
During the canary, compare these records at short intervals. Investigate every mismatch before increasing traffic.
Low lag does not prove that consumers or webhooks finished their work. Custom integration tables may also remain incomplete.
Move state, search, cache, and integrations
Validate each stateful service as a separate migration workstream.
Handle Redis and Varnish safely
Choose one session approach during the switch. Sharing the same Redis session store can preserve shopper sessions.
Separate Redis stores can force re-login. They can also reduce cross-environment key conflicts.
Check Elasticsearch or OpenSearch versions, mappings, analyzers, aliases, and disk space before importing indexes. Reindex catalog search, pricing, and stock-dependent data on the new stack.
Then compare result counts for high-value searches.
Test payments and callbacks end to end
Run real sandbox and controlled live tests for authorization, capture, refund, and 3-D Secure. Test fraud screening, tax quotes, shipping rates, and webhook delivery.
Test guest checkout and logged-in checkout. Test stored payment methods and a failed-card path.
Shift traffic with measurable rollback gates
Move traffic through a load balancer, CDN origin switch, or weighted canary route.
Rehearse the switch before launch
Run one rehearsal 7 to 14 days before a campaign or Black Friday window. Test internal traffic first, then send 1% to 5% through the canary.
Then move to 25%, 50%, and 100%. Increase traffic only when every threshold holds for at least 15 minutes.
Use written go or no-go limits
Proceed only when checkout success stays within 1 percentage point of the old environment. Keep HTTP 5xx below 0.5%.
Keep p95 checkout response time within 20% of baseline. Show payment authorization errors and database lag on one screen.
Also show RabbitMQ queue lag, CPU, memory, and connection pools.
Roll back and reconcile live orders
Name one decision owner, one technical operator, and one customer-support lead. Roll back traffic at once if payment failures rise.
Also roll back when checkout success falls past the agreed limit. Stop if replication lag exceeds the threshold.
Avoid the mistakes that cause loss
Do not schedule the first production move within 14 days of a major promotion. Avoid an international launch or seasonal peak too.
Keep staffed coverage across relevant U.S. time zones. Customers in California, Texas, Ohio, or Virginia may be ordering.
Define the rollback strategy before the first shopper reaches the new origin. Set an RTO, such as five minutes, to restore the prior traffic route.
Set an RPO that states acceptable order or catalog data loss. For most high-volume stores, target zero committed orders lost.
At cutover, fence writes on the old stack. Let active checkout requests finish.
Confirm that payment webhooks and RabbitMQ consumers are drained. Otherwise, confirm that one environment owns them.
If traffic returns to the old application, keep reverse replication validated or keep the new database as the write authority.
In that case, change only the application route.
Record every in-flight order in a reconciliation queue. Compare gateway captures, invoices, refunds, and inventory reservations before closing the rollback.
For a high-traffic ecommerce migration, use a written readiness checklist. This matters near Black Friday, campaign launches, or international sales events.
Confirm peak requests per second and checkout capacity. Check database connections, Redis memory, and queue throughput.
Check CDN behavior and third-party rate limits at the expected regional traffic mix. Validate each storefront's currency, tax, shipping, language, and payment method.
Also validate every local webhook endpoint. This matters where fraud checks or 3-D Secure add latency.
Freeze nonessential catalog imports and extensions. Schedule support and payment-provider contacts.
Keep a tested load balancer cutover path. The final go or no-go review must confirm successful parallel production load tests.
Test projected peak volume plus the planned capacity margin.
Common questions
Can Magento 2 migrate with no downtime?
Yes, when both environments run compatible code and schema. Traffic must shift through reversible routing.
Checkout, payment callbacks, queues, and data replication must stay healthy during the move.
Roll back when HTTP 5xx exceeds 0.5%. Also roll back when checkout success falls over 1 percentage point.
Rollback when payment authorization errors exceed the agreed baseline. Stop when replication lag exceeds 15 seconds during active cutover.
Is DNS cutover safe for Magento?
DNS cutover can work for a planned maintenance move. It is not a fast rollback tool.
Resolver caches may ignore your intended TTL for hours. This can split shoppers between two origins.
Should Redis sessions move to the new host?
Share the existing Redis session store if session continuity matters. Network controls must allow that access.
Use separate stores only when forced re-login is acceptable. You must also understand session key conflicts.
How much does a Magento migration cost?
Cost depends on traffic, integrations, and rehearsal count. A simple managed-host move may take 20 to 40 engineering hours.
A multi-node cloud move often takes 80 to 200 hours. That includes replication, load tests, and payment validation.
Close the migration only after proof
Close the migration only when order counts and payment transactions match. Inventory reservations, queue depth, and integration exports must also match.
Check them across the defined cutover window. Keep backups, monitoring, and the rollback route available.
Keep them until the planned 24- to 72-hour observation period ends.
A Magento migration is complete when customer transactions reconcile correctly. It is not complete when the new domain origin answers requests.
⚠️ Do not delete old database backups, queue logs, or load-balancer history. Wait until finance and operations confirm that all cutover-window orders were reconciled.
