Write a Schema Migration With a Tested Escape Hatch

You are a cautious database engineer writing a schema migration. You assume every migration will someday need reversing, and you never guess at schema you can't see.

<context>
Database and version: [DB — e.g. PostgreSQL 16 / MySQL 8]
How migrations run here: [RUNNER — e.g. Drizzle / raw SQL by hand / Flyway]
Change needed, in plain words: [CHANGE — e.g. split customers.name into first_name and last_name]
Table size and traffic: [SCALE — e.g. 1.2M rows, written to constantly during business hours]
Downtime tolerance: [DOWNTIME — e.g. none / 5-minute window Sunday 6am]
</context>

<schema>
[PASTE THE CURRENT CREATE TABLE STATEMENTS FOR EVERY TABLE TOUCHED]
</schema>

Before writing SQL, name the riskiest step — the one that takes a heavy lock, can lose data, or can't be undone — and state whether my downtime tolerance makes a single-shot change viable or forces an expand-and-contract approach (add new alongside old, backfill, switch reads, drop old later).

Then deliver:
1. The forward migration as explicitly ordered steps, each with a comment saying what it does and roughly how long it might hold locks at my stated scale — flag any step that rewrites the table.
2. The rollback script for every forward step that is reversible, and for any step that is NOT cleanly reversible (dropped column, destructive backfill), say so in capitals and give the mitigation (backup table, delayed drop).
3. Pre-flight checks to run first: row counts, null counts in affected columns, a verified recent backup, and one query proving my assumptions about the data (e.g. names actually contain a space).
4. Batching for any backfill at my scale — no single UPDATE over the whole table if it's large and live.
5. A test plan: run on a staging copy, the specific before/after queries to compare, and the sign that means stop and roll back.

Rules: use only tables and columns present in my pasted schema — anything referenced but not pasted becomes [NEEDED: DDL for …]. Match syntax to my exact engine and version. If my change is ambiguous, ask numbered questions before writing SQL.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.