A new version of an application may need a different shape of data. Existing records and older running versions may still be present while the change is introduced. That overlap is a condition to design for, rather than a detail to discover afterward.
A gradual approach can separate adding a new representation, moving existing information, and removing an old assumption. The right sequence depends on the actual system, including how it is deployed and how a mistake can be recovered.
Rehearse with representative data in an appropriate test environment. Verify both the transformed information and the application actions that use it. A migration succeeds when the surrounding experience continues to make sense.
Picture this situation.
Imagine renaming a stored field while another component still reads the old name. An explicit transition can preserve the ordinary task during the change.
A second way to look.
Look at the information that outlives a single operation. Its owner, meaning, and recovery path deserve as much attention as the operation that created it.
- Consider old and new application behavior.
- Rehearse with representative data.
- Verify the actions that use the changed records.
Follow a related question
Choose a representative sample.
How tools learn to work togetherMatch precision to the reader’s task.
Rounding without losing the pointKeep learning
Related background to continue exploring this subject.
Cloudflare: managing application state AWS: backing up data and verifying recovery