Zero-Downtime Cloud Migration: The Production Checklist

Cloud migration projects fail — not because the technology is hard, but because teams rush the pre-flight checks. After more than 200 production migrations across EMEA for enterprises in finance, healthcare, manufacturing, and public sector, our engineers have distilled everything that matters into a single, repeatable checklist. Use it on your next project.

Phase 1: Discovery & Assessment (4–6 Months Before Migration)

The foundation of any zero-downtime migration is an accurate inventory. Surprises at 2 AM during a cutover window are expensive.

Application Dependency Mapping

Run automated discovery tooling (AWS Migration Hub, Azure Migrate, or open-source tools like Netdata) across all target hosts
Document every inbound and outbound network dependency — do not rely on CMDB alone; it is almost always stale
Identify undocumented integrations: run netstat -an on production hosts and cross-reference with firewall logs for the last 30 days
Flag any hardcoded IP addresses in application configs, connection strings, or startup scripts — these break silently after migration
Map storage dependencies: NFS mounts, SMB shares, iSCSI targets, and local disk paths that applications expect at specific mount points

Performance Baseline Collection

Before you migrate anything, capture the current production baseline:

CPU utilization — p50, p95, and peak over a 2-week window (capture both business hours and off-peak)
Memory footprint — working set size, not just allocation
Disk I/O — read/write IOPS and throughput, latency at p99
Network throughput — east-west traffic between application tiers is frequently underestimated
Application response times — capture at the load balancer level, not just the app server

Store these baselines. You will compare against them post-migration to confirm performance parity before cutting DNS.

Licensing & Compliance Audit

Confirm Microsoft BYOL eligibility if migrating Windows Server workloads — audit SA coverage dates
Verify Oracle Database licensing terms; Oracle’s cloud licensing rules are complex and penalties are significant
Review data residency requirements: GDPR Article 44 restricts personal data transfers outside the EEA without adequate safeguards
Check PCI-DSS scope: migrating cardholder data environments requires a new QSA assessment cycle
Confirm ISO 27001 and SOC 2 control mapping for any regulated workloads — your cloud provider’s shared responsibility model changes what you own

Phase 2: Environment Preparation (2–4 Weeks Before Migration)

Target Environment Build

Provision target infrastructure using infrastructure-as-code only (Terraform, Bicep, or CloudFormation) — no click-ops
Enforce least-privilege IAM from day one: service accounts should have only the permissions required for their specific function
Configure VPC/VNet network segmentation to mirror your on-premises zone model: management, application, database, and DMZ tiers
Deploy monitoring agents to all target hosts before any workloads arrive — Datadog, Azure Monitor, CloudWatch, or Prometheus/Grafana
Validate DNS resolution from all target subnets: forward and reverse lookups, internal resolver configuration, and negative caching TTLs

Network Connectivity Validation

Test private connectivity throughput (AWS Direct Connect / Azure ExpressRoute) under synthetic load — don’t assume the circuit is clean
Validate BGP route advertisement: confirm all on-premises prefixes are reachable from the target VPC and vice versa
Check MTU settings end-to-end: jumbo frames (9001 bytes on AWS, 9000 on Azure) must be consistent across the path or you will see silent packet fragmentation
Confirm security group / NSG rules allow the exact traffic patterns documented in your dependency map — test with curl, telnet, or nc, not just ping

Data Synchronisation Setup

Configure initial bulk replication first, then switch to incremental CDC (Change Data Capture)
For databases: use native tools where possible (SQL Server log shipping, Oracle GoldenGate, PostgreSQL logical replication)
Measure replication lag under production write load — if lag exceeds your RPO target, re-architect before proceeding
Test data integrity: row counts, checksums, and application-level smoke tests on a restored copy of the replicated data

Phase 3: Cutover Execution

The 48-Hour Pre-Cutover Window

Freeze all non-emergency change requests on source systems
Reduce DNS TTLs to 60 seconds for all records that will change (do this 48 hours before cutover so caches drain)
Complete a full disaster recovery test on target: stop the primary, fail over, confirm RTO/RPO, restore primary
Brief on-call engineers with a written runbook — verbal handoffs lose critical context
Confirm rollback triggers: define the specific metrics that will cause you to abort and revert (response time > X, error rate > Y, replication lag > Z)

Cutover Sequence

Quiesce writes on source application tier (put application into read-only mode or behind a maintenance page)
Allow replication to catch up — confirm zero lag before proceeding
Take a final snapshot of source databases as a rollback point
Update application configuration to point to target endpoints (connection strings, service discovery, secret references)
Start application services on target; run smoke tests against the new environment
Update DNS records — do this last, after you have confirmed the application is healthy on the target
Monitor for 30 minutes at minimum before declaring success; keep the source running in read-only mode for at least 24 hours

Validation Checklist (Run After Every Migration)

All health check endpoints return HTTP 200
Authentication flows work end-to-end (SSO, MFA, service accounts)
Background jobs and scheduled tasks are running
Email sending and receiving is functional
All third-party integrations (payment gateways, CRMs, ERPs) have been tested
Log aggregation is flowing to your SIEM
Backup jobs have completed their first successful run on the target
Performance metrics are within 10% of baseline

Phase 4: Post-Migration Hardening (30 Days After Cutover)

Cost Optimisation

Cloud bills surprise teams who migrated like-for-like without right-sizing. Spend the first 30 days:

Reviewing Reserved Instance or Savings Plan recommendations — commit after you have 2 weeks of production data, not before
Enabling automated instance scheduling for non-production environments (dev/test off overnight saves 65–70% of compute cost)
Auditing unattached storage volumes and orphaned snapshots — these accumulate quickly
Setting up budget alerts at 80% and 100% of projected spend with PagerDuty or email escalation

Security Posture Review

Enable cloud provider native security services: AWS Security Hub / Azure Defender for Cloud, GuardDuty / Defender for Servers
Run vulnerability scans on all migrated instances — the migration window often introduces configuration drift
Review public exposure: ensure no storage buckets, databases, or management interfaces are inadvertently internet-accessible
Rotate all service account credentials that were used during the migration process

The One Thing Most Teams Get Wrong

In our experience, the most common cause of migration incidents is underestimating replication lag under real production write load. Teams test replication in staging, see 0 ms lag, and assume production will behave the same. It won’t. Production write amplification — from bulk jobs, end-of-day batch processes, and peak traffic — can push lag to minutes or hours. Always test your replication setup against a production write workload replay before committing to a cutover window.

If you are planning a cloud migration and want a second opinion on your runbook or a discovery assessment of your environment, our EMEA team is available for a complimentary architecture review.