Magento Infrastructure Migrations

#The Problem

Many established Magento stores run on infrastructure from an earlier era — single-server cPanel setups, unmanaged VPS instances, or hosting environments configured for Magento 1 that have been carrying Magento 2 through a series of workarounds. These setups work until they don’t: a hardware failure takes the entire store offline, a traffic spike has nowhere to scale, and any operational change requires manual server access.

The challenge with migrations is that the store cannot go offline. Magento stores process orders continuously. Downtime means lost revenue, failed checkout experiences, and customer trust damage. The migration work is invisible to success but highly visible to failure.

#The Migration Methodology

Developed and refined through multiple production migrations, the methodology prioritises: no data loss, no service interruption, and a clear rollback path maintained until the migration is confirmed stable.

#Phase 1 — Assessment

Before any infrastructure provisioning:

• Architecture audit: Document current server configuration, PHP version, MySQL version, extension matrix, custom code, media storage approach, cron configuration, and any non-standard setup
• Data volume assessment: Database size, media storage size, average daily data growth
• Traffic baseline: Peak request rates, Varnish hit rates (if applicable), database connection peaks
• Risk register: Specific migration risks — conflicting extension versions, custom server configuration dependencies, DNS propagation timelines, critical order volumes that make window selection constrained

#Phase 2 — Target Infrastructure

New infrastructure provisioned and validated in full before any traffic movement begins.

• Full Magento stack deployed on target architecture
• Magento installed and configured matching the source environment
• All extensions installed, configured, and verified
• Performance benchmarks run — target environment must match or exceed source baseline

The target environment is fully production-ready before the migration begins. This is the expensive step in time (provisioning and configuration) but eliminates risk in the cutover step.

#Phase 3 — Data Migration

Data migration uses a point-in-time incremental sync approach:

1. Initial sync: Full database dump from source, imported to target. Takes the bulk of the migration time — run well in advance of cutover
2. Incremental sync: Periodic delta syncs in the days before cutover, narrowing the data gap
3. Pre-cutover sync: Final sync triggered as close to the cutover window as practical, minimising the remaining delta
4. Cutover sync: At the moment of DNS cutover, a final incremental sync captures any orders or registrations placed during the cutover window

Media files (product images, customer uploads) synced via rsync, incremental, with a final sync immediately before cutover.

#Phase 4 — DNS Cutover

TTL pre-reduction: 7 days before cutover, TTL on the store’s DNS records is reduced to 60 seconds. This limits the propagation window for the actual cutover change.

Health checks: Both old and new infrastructure health endpoints monitored from multiple locations before triggering cutover.

Cutover: DNS records updated to point to new infrastructure. With 60-second TTL, the transition completes globally within minutes.

Monitoring: Both old and new infrastructure monitored simultaneously during the propagation window. Traffic gradually shifts as DNS caches expire.

Rollback availability: Old infrastructure maintained in full operational state for 72 hours post-cutover. Rollback is a single DNS record change with immediate effect.

#Phase 5 — Post-Migration Monitoring

72-hour enhanced monitoring window after cutover:

• APM error rate and response time tracked against pre-migration baseline
• Database query performance compared to source environment baseline
• Varnish hit rate monitored for configuration issues
• Cron job execution verified
• Email delivery tested

Old infrastructure decommissioned only after the 72-hour window closes clean.

#Migration Types Completed

cPanel → containerised multi-service: Moving from shared-host-style single-server setups to Warden-based containerised stacks with separate service tiers. Common for stores that started on budget hosting and outgrew it.

Magento 1 end-of-life infrastructure → Magento 2 modern hosting: Combined platform migration and infrastructure migration. The infrastructure move is sequenced separately from the platform migration to isolate risk.

Legacy VPS → HA multi-server: Moving from single-server setups to load-balanced multi-node architectures with Redis Cluster and MySQL replicas.

Cross-datacenter migrations: Moving between cloud providers or regions, including cases with contractual deadline requirements.

#What We Learned

The initial data sync is the step that determines whether the cutover window is comfortable or stressful. A large initial sync done well in advance, followed by small incremental syncs, means the cutover sync is a matter of minutes rather than hours. Stores where we tried to compress the timeline and cut initial sync time experienced more stressful cutovers.

The rollback window is psychologically as important as operationally. Knowing that old infrastructure is available and functional for 72 hours changes how the team approaches the cutover — as a recoverable operation rather than a point of no return.