Database Migration Checklist

Capture exact version, edition (Standard / Enterprise), patch level, collation, and character set. SQL Server Standard-to-Enterprise feature gaps and Oracle Standard Edition 2 socket limits are common surprises that surface mid-migration.

List every connection string, linked server, ETL job, BI report, and SaaS integration that touches this database. Pull from connection logs over a 30-day window — application owners always forget at least one cron job.

Flag PHI (HIPAA), cardholder data (PCI DSS), or EU personal data (GDPR). Regulated workloads constrain target region selection, encryption requirements, and who can touch the data during cutover.

Document the maximum acceptable data loss (RPO) and downtime (RTO) in writing. These two numbers drive whether you can do an offline export-import or need log shipping / native replication / a third-party tool like Qlik Replicate or AWS DMS.

Provision compute, memory, and IOPS based on source baseline (peak QPS, peak connections, working set). Right-size with 30% headroom; cloud DBs (RDS, Azure SQL, Cloud SQL) make resizing easy but storage IOPS tiers often require a maintenance window to change.

Place the target in a private subnet with explicit allow-lists for application tiers and admin jump hosts. Block public access at the security group AND the engine level (e.g., RDS publicly_accessible=false). Document the network path the application will use post-cutover.

Use a customer-managed KMS key (not the default AWS/Azure-managed key) so key access can be revoked independently. Force TLS 1.2+ at the engine level and update the application's CA bundle to the cloud provider's root.

Set retention to match the data retention policy (commonly 35 days for PITR plus longer-term snapshots to S3 / Blob with object lock for ransomware resilience). The 3-2-1 rule applies — at least one immutable copy in a separate account.

Run the backup with checksum verification (SQL Server CHECKSUM, pg_basebackup with -P, RMAN VALIDATE). A backup that completes without checksum is not a verified backup — it's a file of unknown quality.

Restore into a sandbox VPC / instance — not production, not the migration target. The backup-runs-nightly-restore-never-tested pattern is the most common DR failure; the drill is what proves the backup is usable.

Spot-check row counts on the top 20 largest tables and run a checksum (CHECKSUM_AGG, pg_checksums, or DBMS_SQLHASH) on a sample. Differences here mean the migration plan needs revision before cutover.

File the RFC with the cutover plan, rollback plan, communication plan, and named approvers. Include the maintenance window, expected downtime, and the engineer-on-keyboard for the change.

Send the maintenance notice to application owners, customer success, and any external customers covered by SLA. Include start time, expected duration, status page link, and the rollback decision time.

Put the application in maintenance mode, revoke write permissions, and wait for in-flight transactions to drain. Confirm zero active sessions before proceeding — a half-committed transaction is the worst kind of migration error.

If using AWS DMS / Azure DMS / Qlik Replicate / native log shipping, wait for replication lag to reach zero, then stop the task. For offline strategy, run the final incremental dump and import.

Update connection strings via secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) so the change is auditable and reversible. DNS-based cutover (CNAME flip) is faster to roll back than redeploying the application.

Reverse the connection string change via the secrets manager. The source must still be writable — do not decommission until the post-migration review is complete.

Snapshot the target as-is before any cleanup so the post-mortem has the actual state of failure. Pull engine logs, replication task logs, and slow query logs.

Compare row counts and aggregate checksums on every table over a defined size threshold. Investigate any mismatch immediately — silent data loss is the worst migration outcome.

Walk the top user journeys with the application owner: authentication, search, write paths, scheduled jobs, and any third-party integrations. Confirm BI dashboards and ETL jobs ran successfully on the next cycle.

Pull the top 50 slowest queries (pg_stat_statements, sys.dm_exec_query_stats, V$SQL) and compare p95 latency against the source baseline. New plans, missing indexes, and stale statistics show up here first.

Hold the source in read-only state for at least 14 days post-cutover. Take a final cold archive snapshot to immutable storage before destroying instances; document destruction per the data retention policy.