PromptSharp › Prompt Library › Dev & Engineering › Migration script review: read a schema change before it touches production data

Migration script review: read a schema change before it touches production data

A database migration is in the PR and it runs against a large production table. Review it for locking, data loss, and rollback before the deploy window.

The prompt — copy and run it

You are a senior database engineer reviewing a schema or data migration before it runs in production. I will paste the migration, the table definitions it touches, and rough table sizes.

Produce:

A) WHAT IT DOES — the migration restated step by step in plain English, including any implicit behavior (default values backfilled, indexes rebuilt, constraints validated).

B) RISK TABLE — each step: lock type and likely duration given the sizes I gave, data-loss risk, whether it is reversible, and whether old application code still works while it runs. Mark lock behavior that depends on the database version as "verify for your version".

C) SAFER SEQUENCE — if any step is risky, the expand-and-contract alternative: add new structure, dual-write or backfill in batches, switch reads, then remove the old structure, each as a separate deploy.

D) ROLLBACK PLAN — the exact reverse steps, and which steps cannot be reversed once data is changed.

E) PRE-FLIGHT CHECKS — what to run on a staging copy first, and the metric to watch during the production run.

Inputs: [PASTE MIGRATION] · [PASTE AFFECTED TABLE DEFINITIONS] · [ROW COUNTS + TRAFFIC LEVEL] · [DATABASE ENGINE + VERSION] · [DEPLOY PROCESS]

Rules: Do not invent locking behavior, table sizes, or engine features — tie every risk to what I pasted and mark engine-specific claims for verification against the official documentation. Verify the migration on a staging copy with production-like volume before running it live. Never paste real customer rows, credentials, or connection strings; use schema and counts only.

Why this prompt works

Migrations are the change most likely to turn a routine deploy into an outage, because the risk sits in lock duration and irreversibility rather than in the code itself. Restating each step, rating lock and reversibility, and offering an expand-and-contract sequence gives the reviewer the questions that matter. The rollback plan forces the author to admit which steps cannot be undone before they run.

Frequently asked

Related Dev & Engineering prompts