Renaming a database column looks like a small change until an older application instance still tries to read it. Rolling deployments create a period when multiple software versions share the same data. A migration plan needs to support that overlap deliberately.
Add the new shape before removing the old one
The parallel change pattern separates expansion, migration, and contraction. For an illustrative change from a single address field to structured address fields, first add the new fields without removing the original. Deploy code that can work while existing rows are incomplete.
Decide which representation is authoritative during the transition. If both are written, define how partial failures are handled and how divergence is detected. Avoid assuming that two independent writes will always succeed together.
Treat the data migration as a resumable job
Backfill in bounded batches, record progress, and make repeated processing safe. Test against representative row counts and values before selecting a batch size. Watch locking, database load, and replication lag where replication is used.
Some old values will not translate cleanly. An address stored as free text may lack a reliable postal-code boundary. Keep those records available for review instead of inventing missing data. Verify the business meaning of the transformed values, not only the number of rows updated.
Remove compatibility only after observation
Switch readers after validation, then observe whether any old application, report, or scheduled job still depends on the original field. Keep a defined rollback window before removing it. Once old data is dropped, rolling application code back may no longer be sufficient; document whether recovery requires a data restore or a forward repair. Make the cleanup a scheduled deliverable so temporary compatibility does not become permanent confusion.
