Cloud database migration checklist

1. Preparation and decision

• Write down RPO/RTO targets; get stakeholders to sign off on the accepted downtime.
• Choose the target service: managed (Azure SQL / RDS / Cloud SQL) or on a VM?
• Version and compatibility gap analysis: character set, collation, extensions, jobs and triggers.
• List dependencies: linked servers, external service calls, file-system access, scheduled tasks.
• Measure data size, daily change volume and the largest tables; estimate replication time.

2. Landing zone (target environment)

• Network: VPC/VNet, subnets, private endpoints, security groups; VPN/Direct Connect to on-prem.
• Identity and access: least privilege, service accounts, secret management.
• Encryption: data at rest and in transit; key management.
• Backup policy, retention period and a point-in-time recovery (PITR) test.
• Monitoring: metrics, logs, alert thresholds and a dashboard — ready before the migration.
• Everything as code (IaC): you must be able to rebuild the environment.

3. Online replication

• Set up an initial load plus continuous change capture (CDC / logical replication / DMS).
• Monitor replication lag; it must be near zero before cutover.
• Move schema objects manually: users/roles, permissions, job schedules, connection strings.
• Point the application at the target and run read-only and functional tests.
• Measure a performance baseline on the target; adjust right-sizing.

4. Rehearsal cutover (dress rehearsal)

• Run the real cutover steps at least once in a test environment (or a copy), timing each step.
• Every step should have an owner, a command and an expected output written in the runbook.
• Prepare a verification list: row counts, checksums, critical business flows.
• Rehearse the rollback scenario too — how do you return to the source?

5. Cutover

• Enter maintenance mode / stop write traffic.
• Wait for the last changes to be applied to the target (lag = 0).
• Synchronise sequence/identity values.
• Run the verification list; try critical business flows live.
• Switch the connection string/DNS; make the old source read-only (don't delete it yet).
• Watch monitoring closely: error rate, latency, locking.

6. After the migration

• 24–72 hours of close observation; track performance and cost metrics.
• Right-sizing, reservation/saving plans and shutting down unnecessary environments.
• Decommission the old source in a planned way once the rollback window has closed.
• Update the runbook and architecture doc; write down lessons learned.

We can adapt this list to your environment and run the migration with you — see our Managed Database service.