Looking at the diff, I see 23 changed tables. Three of them are immediately risky and the rest split cleanly. **Safe to drop (8 tables)** — referenced only by deprecated reports we already turned off. The orphan rows can go. **Backfill required (12 tables)** — adding a NOT NULL column with a default. Backfill in batches of 5k rows over a quiet window; use a marker column to track progress so a re-run is idempotent. **Feature-flag (3 tables)** — `accounts`, `deals`, `activities`. These power the live UI. Ship the new schema dark, double-write for 7 days, flip readers, then drop the legacy columns. Want me to drill into the double-write strategy for the live tables?

Double-write pattern (writes hit both shapes, reads still hit the old shape): 1. Add the new columns NULL-able first. Code path writes both old and new. 2. Backfill the new columns from the old ones in batches. 3. Add CHECK constraints once the backfill is done. 4. Flip readers progressively (5% / 25% / 100% over a week). 5. Drop the old columns in a follow-up migration. Sanity-check query — run nightly during the migration window: ```sql SELECT COUNT(*) FILTER (WHERE legacy.amount_cents IS DISTINCT FROM new.amount_minor_units) AS mismatches, COUNT(*) AS total FROM deals legacy JOIN deals_v2 new USING (id) WHERE legacy.updated_at > now() - interval '24 hours'; ``` Any non-zero `mismatches` means a write path missed the double-write. Page on it.