Why write a migration plan instead of just running the SQL?

A written plan forces you to think through pre-checks, ordering, validation, and rollback before touching production. It also gives reviewers and on-call engineers a runbook to follow if something goes wrong at 3am.

What is the expand-and-contract pattern?

Expand-and-contract ships a migration in phases: first add the new column or table (expand) while the app writes to both, then backfill, then remove the old structure (contract) in a later release. It keeps schema changes backward compatible and avoids downtime.

Why include validation queries?

Validation queries prove the migration did what you intended — row counts match, no NULLs where there should be data, foreign keys resolve. Running them right after the migration catches silent corruption before users do.

Do I always need a rollback script?

For anything reversible, yes — a rollback script lets you revert quickly under pressure. Some migrations (like dropping a column with data) are not cleanly reversible, in which case the plan should note that and rely on a database backup instead.

How accurate is the estimated duration?

Duration depends on row counts, indexes, and locking, so treat the figure you enter as a rehearsed estimate from a staging run rather than a guarantee. For large tables, prefer online or batched migrations to avoid long locks.

Database Migration Plan Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Turn a risky schema change into a repeatable runbook

Schema migrations are one of the highest-risk things you can do to a production system: get the ordering wrong, skip a backfill, or forget a rollback and you can corrupt data or lock a table for minutes. This builder structures the change into a runbook — pre-checks, steps, validation, and rollback — so the plan is reviewable before anyone runs it.

How it works

You describe the migration name, target table, and engine, then list pre-migration checks, the forward SQL steps, validation queries, and rollback SQL. The tool assembles a Markdown runbook with numbered phases following the expand-and-contract mindset: verify preconditions, apply changes in order, validate the result, and keep a tested rollback ready. The estimated-duration field reminds you to rehearse on staging so the production window is realistic. Nothing is executed — the output is a document you paste into your deployment process.

Tips and example

Prefer additive steps first: ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT false; is safe and non-locking on most engines.
Backfill in batches for large tables to avoid long locks, e.g. update 10,000 rows per statement in a loop.
Write validation queries that compare counts before and after, such as SELECT count(*) FROM users WHERE email_verified IS NULL;.
Keep the rollback in the same plan and test it on staging — an untested rollback is not a rollback.