1# Data Migration Specialist Review Checklist

3Scope: When SCOPE_MIGRATIONS=true

4Output: JSON objects, one finding per line. Schema:

5{"severity":"CRITICAL|INFORMATIONAL","confidence":N,"path":"file","line":N,"category":"data-migration","summary":"...","fix":"...","fingerprint":"path:line:data-migration","specialist":"data-migration"}

6Optional: line, fix, fingerprint, evidence, test_stub.

7If no findings: output `NO FINDINGS` and nothing else.

8

9---

10

Data Migration Specialist Review Checklist

Scope: When SCOPE_MIGRATIONS=true Output: JSON objects, one finding per line. Schema: {"severity":"CRITICAL|INFORMATIONAL","confidence":N,"path":"file","line":N,"category":"data-migration","summary":"...","fix":"...","fingerprint":"path:line:data-migration","specialist":"data-migration"} Optional: line, fix, fingerprint, evidence, test_stub. If no findings: output NO FINDINGS and nothing else.

Raw lines 1 to 10

11## Categories

12

Categories

Raw lines 11 to 12

13### Reversibility

14- Can this migration be rolled back without data loss?

15- Is there a corresponding down/rollback migration?

16- Does the rollback actually undo the change or just no-op?

17- Would rolling back break the current application code?

18

Reversibility

Can this migration be rolled back without data loss?
Is there a corresponding down/rollback migration?
Does the rollback actually undo the change or just no-op?
Would rolling back break the current application code?

Raw lines 13 to 18

19### Data Loss Risk

20- Dropping columns that still contain data (add deprecation period first)

21- Changing column types that truncate data (varchar(255) → varchar(50))

22- Removing tables without verifying no code references them

23- Renaming columns without updating all references (ORM, raw SQL, views)

24- NOT NULL constraints added to columns with existing NULL values (needs backfill first)

25

Data Loss Risk

Dropping columns that still contain data (add deprecation period first)
Changing column types that truncate data (varchar(255) → varchar(50))
Removing tables without verifying no code references them
Renaming columns without updating all references (ORM, raw SQL, views)
NOT NULL constraints added to columns with existing NULL values (needs backfill first)

Raw lines 19 to 25

26### Lock Duration

27- ALTER TABLE on large tables without CONCURRENTLY (PostgreSQL)

28- Adding indexes without CONCURRENTLY on tables with >100K rows

29- Multiple ALTER TABLE statements that could be combined into one lock acquisition

30- Schema changes that acquire exclusive locks during peak traffic hours

31

Lock Duration

ALTER TABLE on large tables without CONCURRENTLY (PostgreSQL)
Adding indexes without CONCURRENTLY on tables with >100K rows
Multiple ALTER TABLE statements that could be combined into one lock acquisition
Schema changes that acquire exclusive locks during peak traffic hours

Raw lines 26 to 31

32### Backfill Strategy

33- New NOT NULL columns without DEFAULT value (requires backfill before constraint)

34- New columns with computed defaults that need batch population

35- Missing backfill script or rake task for existing records

36- Backfill that updates all rows at once instead of batching (locks table)

37

Backfill Strategy

New NOT NULL columns without DEFAULT value (requires backfill before constraint)
New columns with computed defaults that need batch population
Missing backfill script or rake task for existing records
Backfill that updates all rows at once instead of batching (locks table)

Raw lines 32 to 37

38### Index Creation

39- CREATE INDEX without CONCURRENTLY on production tables

40- Duplicate indexes (new index covers same columns as existing one)

41- Missing indexes on new foreign key columns

42- Partial indexes where a full index would be more useful (or vice versa)

43

Index Creation

CREATE INDEX without CONCURRENTLY on production tables
Duplicate indexes (new index covers same columns as existing one)
Missing indexes on new foreign key columns
Partial indexes where a full index would be more useful (or vice versa)

Raw lines 38 to 43

44### Multi-Phase Safety

45- Migrations that must be deployed in a specific order with application code

46- Schema changes that break the current running code (deploy code first, then migrate)

47- Migrations that assume a deploy boundary (old code + new schema = crash)

48- Missing feature flag to handle mixed old/new code during rolling deploy

Multi-Phase Safety

Migrations that must be deployed in a specific order with application code
Schema changes that break the current running code (deploy code first, then migrate)
Migrations that assume a deploy boundary (old code + new schema = crash)
Missing feature flag to handle mixed old/new code during rolling deploy

Raw lines 44 to 48

data-migration.md