Test a database migration without losing user data
A database migration works on your phone and fails on one from a user who skipped three versions. The damage is data loss, which users do not forgive. Test upgrades as a feature, not as an afterthought.
Build a matrix of old versions
List every version of your schema that is still in the wild. For each one, keep a database file or an app build that creates it. Then migrate each to the current version, not only the previous one. Users on old devices skip updates.
Test with realistic data
- A nearly empty database and a large one with thousands of rows.
- Rows with nulls, very long text, emoji and unusual characters.
- Data created by earlier bugs. Old versions wrote things you would not write today.
Check more than "it opens"
After the migration, compare row counts and sample values against the old file, run the main screens and check that the app can still write. A migration that succeeds but leaves a column empty is the worst case, because nothing crashes.
Automate the base case
Frameworks such as Room (Android) and Core Data or GRDB (iOS) support migration tests: open an old schema, run the migration, assert the result. Put these in your build so they run on every change.
Plan for failure
Back up before a destructive step when you can, and make the migration run in a transaction so a failure rolls back instead of leaving half a schema. Log the failure so you see it in crash reports.
Questions developers ask
Can I just drop the table and re-sync? Only if the data lives on a server and you are sure the sync is complete. Local-only data would be gone.
How do testers help? Ask testers who have the old build installed to update instead of installing fresh. That is the real upgrade path.
Need testers for your app? Open a test group on AppReviewX. Start free