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.

Choose between an offline cutover (downtime window for full export/import), an online migration (replication keeps target in sync until cutover), or a phased migration (tenant-by-tenant or schema-by-schema). The choice locks in toolchain and rollback plan.

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.

Connect the target to Datadog / CloudWatch / Azure Monitor with alerts for replication lag, CPU, IOPS saturation, connection count, and long-running queries. Page the on-call rotation via PagerDuty / Opsgenie before the cutover window, not after.

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.

Write the rollback runbook before the cutover, not during. Include: how to repoint the application, how long the source must remain writable, and the exact decision criteria for calling rollback during the change window.

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.

Run smoke tests against the application: login, read, write, the top 5 critical user journeys. Decide go / no-go before the rollback window closes — partial cutovers that drag past the window are how outages turn into incidents.

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.

Run a blameless post-mortem within 5 business days, identify the root cause, and reschedule the cutover only after the underlying issue is fixed and re-tested in the drill environment.

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.

The DBA, application owner, and change manager sign off the migration as complete. Attach the cutover log, reconciliation results, and any open follow-up tickets.