Database Migration Checklist Template

The migration type and downtime approach recorded on the first task decide which tasks appear in Phases 2, 4 and 5.

• Open the migration record and set the type, approach and owners — version upgrade, platform move or engine change; offline or online; the database owner, application owner and change owner
• Measure the size and the rate of change — data and log volume, the largest tables and the changes per hour at peak, which set how long copying and catching up will take
• Inventory everything in and around the database — schemas, procedures, triggers, scheduled jobs, linked servers, extensions, logins and encryption settings
• Find every client that connects — application configs, reports, ETL jobs and spreadsheets; the database’s own connection logs show who really uses it
• Check the target supports what you use and how it is licensed — managed services drop some features, extensions and operating system access
• Agree the downtime the business will accept — in minutes, from the application owner; it decides between offline and online

The first three tasks appear only for an engine change.

• Run a conversion assessment and size the manual work — a report of what converts automatically and what has to be rewritten by hand
• Convert the schema and rewrite what did not convert — procedures, functions, data types, sequences and implicit conversions
• Test the application’s queries against the converted schema — sorting, null handling, case sensitivity and date arithmetic differ between engines
• Build the target and apply the schema with indexes and constraints held back — secondary indexes, foreign keys and triggers slow the bulk load or break it
• Recreate logins, permissions and scheduled jobs on the target — data migration tools move tables, not users or agent jobs
• Choose and record the migration method — backup and restore, native replication, dump and load or a managed migration service, and why

• Capture a performance baseline on the source — the slowest and most frequent queries and key transaction times, across a full business cycle
• Rehearse the whole migration on production-sized data — and time every step: copy, catch-up, index builds, validation and repointing
• Validate the rehearsal copy with the checks planned for cutover — row counts, checksums and sample queries, so the checks themselves are tested
• Run the application tests and baseline queries against the rehearsal copy — a slow query found now is a tuning task; found after cutover it is an incident
• Write the cutover runbook from the rehearsal timings — each step with an owner, a measured duration and the check that proves it worked
• Set the rollback point and the trigger — the last moment you can still go back, and what happens to writes made on the target after it

The replication tasks appear only for an online migration. The change owner records Approved or Not approved on the last task, and the checklist halts until they decide.

• Start the full load and change data capture — add secondary indexes before the change phase begins, so applying changes does not scan whole tables
• Watch replication lag and validation results until cutover — batch jobs and index rebuilds on the source can push lag to minutes or more
• Take a full backup of the source and prove it restores — this is the copy you fall back to if everything else fails
• Freeze schema changes and releases on the source — a column added mid-migration breaks the copy or silently misses the target
• Tell users, the service desk and integration owners the window — what stops, for how long and who to call
• Approve or reject the cutover — the change owner records the decision, with the rehearsal timings and validation results attached

The final copy appears for an offline migration; draining replication appears for an online one.

• Stop application writes and record the time — maintenance mode on, source jobs disabled, sessions drained
• Take the final backup or dump and load it on the target — timed against the rehearsal; past the trigger, roll back
• Let the last changes apply, then stop replication — lag at zero and the final change applied before anything points at the target
• Enable constraints, triggers and jobs on the target — foreign keys validated, not just switched on
• Run the cutover validation checks — row counts on every table, checksums on key tables and the sample queries the application owner chose
• Repoint applications, reports and integrations to the target — connection strings, DNS aliases and data source definitions
• Go live or roll back at the trigger time — after the application owner’s smoke test; rolling back means pointing clients at the untouched source

• Watch errors, connections and blocking for the first business day — a client still connecting to the old server shows up in its logs
• Compare performance with the source baseline — the same queries at the same load, fixing regressions with indexes, statistics or plan guidance
• Refresh statistics and confirm maintenance jobs run — index maintenance, integrity checks and statistics updates on their new schedule
• Confirm backups run on the target and test a restore — a managed service’s defaults may not match your retention policy
• Record the application owner’s acceptance — Accepted, or Not accepted with the open issues listed

• Keep the source read-only until the rollback period ends — stopped or read-only, never deleted while a rollback is possible
• Hand the old instance to server decommissioning — backup jobs, monitoring, firewall rules and service accounts all go
• Cancel the source’s licences and support contracts — the saving only arrives when they stop
• Close the change and update the CMDB and runbooks — with the validation evidence and acceptance attached