The Database Migration Checklist for Consultants

Why consultants need a written checklist, not memory

Every database migration checklist a consultant runs looks slightly different by client, but the failure modes are almost always the same regardless of the specific database engines involved: an untested backup, an assumption about data types that turns out to be wrong, or a rollback plan that exists only as an idea rather than a tested procedure. Working from a written checklist rather than experience alone matters most under pressure, during a live cutover window, when it is easy to skip a step that seemed obvious in planning but gets forgotten once something starts going wrong in real time.

Phase 1: inventory and risk assessment

Before touching any data, a database migration checklist should start with a complete inventory: every table, its approximate row count, any custom stored procedures or triggers, and every application or integration that reads from or writes to the database. This phase should also flag anything unusual — non-standard character encodings, extremely large BLOB columns, or foreign key relationships that span multiple systems — since these are exactly the details that get missed in a rushed migration and cause the most painful failures afterward, often not surfacing until well after the migration is declared complete.

Phase 2: a backup is not done until it has been restored

A backup that has never been restored is not a verified backup, it is an assumption. A responsible database migration checklist treats the restore test as a mandatory step, not an optional one: take the backup, restore it to a separate environment, and confirm the row counts, spot-check the data, and verify the application can actually run against the restored copy. This step alone catches a meaningful share of migration disasters before they happen, because a corrupted or incomplete backup discovered during a restore test is an inconvenience, while the same discovery made mid-migration with the original data already altered is a genuine crisis.

Phase 3: schema and data-type mapping

Moving data between different database engines, or even between major versions of the same engine, means data types do not always translate directly. A thorough database migration checklist documents exactly how each source column maps to its destination equivalent, flags any fields at risk of silent truncation or encoding corruption, and confirms date and time fields carry timezone information consistently across the migration rather than shifting silently. This mapping document becomes the reference both the consultant and client return to when something looks different after migration, rather than relying on memory of a decision made weeks earlier.

Phase 4: the dry run on a real copy of production

Running the full migration process against a realistic copy of production data, on a schedule that mimics the actual cutover window, is the step most often skipped under time pressure and the one most responsible for surprises when it is. A dry run surfaces problems a checklist alone cannot predict: how long the migration actually takes at real data volume, whether any step silently fails on edge-case data the source system happens to contain, and whether the destination environment performs acceptably once real query patterns hit it. A database migration checklist without a dry run step is a plan, not a tested plan.

Phase 5: a rollback plan the client actually agrees to

Every database migration checklist needs an explicit rollback trigger and procedure, agreed with the client in writing before the migration window opens: what specific condition triggers a rollback decision, how long the team will wait before deciding, and exactly what steps restore the previous system to working order. Consultants who skip this conversation in advance end up negotiating rollback criteria live, under pressure, mid-incident — exactly the wrong time to be making a decision that should have been settled calmly days earlier with everyone’s agreement already on record.

Executing the live cutover window

On migration day, the database migration checklist becomes a literal runbook: freeze writes to the source system at an agreed time, run the migration, validate row counts and spot-check critical records against the source, cut the application over to the new database, and keep the old system available read-only for a defined grace period in case a discrepancy surfaces after cutover that the validation step missed. Documenting the actual timestamps of each step as it happens, rather than reconstructing them afterward, gives both the consultant and client a clear record if anything needs to be investigated once traffic returns to normal.