IT / DevOps · Letter D

Database Migration Runbook

A rehearsed, time-ordered procedure for changing production data or schema with clear validation, pause points, ownership and recovery actions.

By Dr. Hassan Eliwa, PhD · Founder of PMMilestone.org and PMMilestone.com · Updated 2026-09-29

Definition

Database Migration Runbook — A database migration runbook translates a schema or data change into an executable production procedure. It names prerequisites, commands or jobs, expected timings, observability, validation queries, stop conditions, communication and rollback or roll-forward actions.

Why It Matters in Practice

This control matters because the cost of a weak decision rarely appears at the moment it is made. It surfaces later as delay, rework, unsafe improvisation or an argument about what the team believed. Experienced teams make the decision visible, assign ownership and preserve evidence while options are still open.

A Working Method

  1. Rehearse against realistic volume and data distribution.
  2. Separate expand, migrate and contract steps across releases.
  3. State numeric stop conditions for locks, latency, errors and replica lag.
  4. Make every step idempotent or record exactly how to resume it.
  5. Validate business invariants, not only row counts.

Real-World Example

A SaaS team needed to backfill tenant IDs into 180 million event rows. The first draft said run migration and monitor. A rehearsal on a production-sized copy showed the update held locks long enough to delay writes. The revised runbook added 10,000-row batches, replica-lag and lock-wait stop thresholds, a pause command, hourly checkpoints and dual-read validation. Production backfill took eleven hours rather than the optimistic three, but customer latency stayed within target and the process paused twice automatically when replica lag rose.

Practical Lessons Learned

  • Rehearse against realistic volume and data distribution.
  • Separate expand, migrate and contract steps across releases.
  • State numeric stop conditions for locks, latency, errors and replica lag.
  • Make every step idempotent or record exactly how to resume it.
  • Validate business invariants, not only row counts.

Controls and Evidence

The production record should preserve the approved runbook revision, operator timeline, command or job identifiers, dashboard links, checkpoints, pauses, validation output and final decision. Log expected and actual duration for each major step. For a long backfill, retain the last committed key or batch so recovery does not depend on memory. A retrospective should update both the migration pattern and future estimates. This turns one safe execution into reusable organisational knowledge instead of a heroic event known only to the engineer who ran it.

Expert Tips

  • Field tip: A runbook is valuable because it is executable under pressure.
  • Field tip: Production-sized rehearsal exposes lock and duration risks.
  • Field tip: Expand-and-contract preserves compatibility and recovery options.
  • Field tip: Explicit stop conditions turn monitoring into a control.

Common Mistakes

  • Treating a successful small staging run as production proof.
  • Combining schema removal and application switch in one irreversible step.
  • Writing 'monitor closely' without named metrics or thresholds.
  • Assuming rollback is possible after destructive data transformation.
  • Leaving ownership unclear when the run exceeds its window.

Key Takeaways

  • A runbook is valuable because it is executable under pressure.
  • Production-sized rehearsal exposes lock and duration risks.
  • Expand-and-contract preserves compatibility and recovery options.
  • Explicit stop conditions turn monitoring into a control.

Related Concepts

Connect this practice with Schema Change Discipline, Zero Downtime Migration, Backup Restore Drill, Runbook. The value comes from using these controls together rather than treating each as an isolated checklist.

Frequently Asked Questions

  • What belongs in a database migration runbook?
    Prerequisites, owners, exact steps, timings, expected results, dashboards, validation, pause and stop thresholds, recovery actions and communications.
  • Can every migration be rolled back?
    No. Rollback isn't always possible; destructive transformations may require restore or roll-forward instead. The runbook must state the real recovery strategy before execution.
  • Why use expand-and-contract?
    It keeps old and new application versions compatible while columns or data are introduced, backfilled and validated before old structures are removed.
  • What did rehearsal change in the SaaS backfill?
    It exposed write-blocking locks, so the team used small batches, automatic lag thresholds and resumable checkpoints. The job ran longer but avoided customer impact.
  • How are stop conditions chosen?
    From service objectives and database safety limits: lock waits, error rate, latency, replication lag, disk growth and job throughput. Use numbers and owners, not judgement alone.
  • When is the migration complete?
    After data and business invariants pass, application behaviour is stable, monitoring shows no regression, temporary compatibility code is removed and evidence is recorded.
  • Which calculators on PMMilestone.org apply to Database Migration Runbook?
    For Database Migration Runbook, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.
  • What is a common misconception about Database Migration Runbook?
    That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.
  • Which related encyclopedia entries should I read alongside Database Migration Runbook?
    Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.
  • How does Dr. Hassan Eliwa's research treat Database Migration Runbook?
    Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Database Migration Runbook is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.
  • How is Database Migration Runbook defined on PMMilestone Research & Insights?
    A rehearsed, time-ordered procedure for changing production data or schema with clear validation, pause points, ownership and recovery actions. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

People also ask

Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.

Related Entries

Further reading on PMMilestone.org

Curated companion resources hosted on the flagship platform, PMMilestone.org.

Related Encyclopedia Entries
Research Articles
Career Guides
Tools on PMMilestone.org
Buy me a coffee