Database Migration Checklist Template

Phase 1: Scope & Assessment

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

Phase 2: Schema, Code & Method

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

Phase 3: Rehearsal & Baseline

• 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

Phase 4: Sync, Freeze & Go/No-Go

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

Phase 5: Cutover

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

Phase 6: Post-Cutover Monitoring

• 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