A mobile release can work perfectly on a fresh test device and still fail when installed over an older version with saved data. If the app stores drafts, cached records or queued actions, ask the agency to include upgrade paths in acceptance. The question is what happens to real existing state, not only whether the new app starts.
Related service: Mobile application development- 01Identify stored data
- 02Prepare versioned migration
- 03Upgrade representative old states
- 04Verify recovery and sync
SECTION 01
Ask what is stored only on the device
List drafts, pending uploads, offline edits, reference caches and account-specific settings. Mark which data can be recreated from the server and which cannot. A migration should preserve meaning as well as fields: an old status value may need a deliberate mapping rather than merely a renamed column.
Android's database migration documentation shows why destructive fallback can remove existing data. The implementation may use a different storage technology, but the buyer's acceptance concern remains the same. Ask for an explicit supported upgrade matrix, including users who move from an older installed release directly to the current one.
SECTION 02
Illustrative example: adding a required inspection field
A field-service app introduces a new required inspection category. A technician has several offline drafts created before that field existed. The update should preserve their notes and photographs, mark the missing category for completion and avoid inventing a selection that the technician never made.
After the technician chooses the category, the app revalidates and synchronizes the draft. If the old draft cannot be converted automatically, it remains available through the agreed recovery route. This hypothetical example distinguishes a valid migration from simply making the new screen open with empty data.
SECTION 03
Test updates and restores as separate paths
Install the new release over realistic older data, interrupt the upgrade where feasible, and verify restart behavior. Test near-full device storage and a queued upload referencing a local file. Android's backup documentation also distinguishes included and excluded data; a restored backup may contain an older structure or device-specific values that need special handling.
At handoff, request schema history, migration tests, backup rules and instructions for diagnosing failed upgrades. A server-first app with disposable local cache may need a simpler strategy than a deeply offline app. Make that tradeoff before promising offline capability, because preserving local-only work adds ongoing release responsibilities.
SECTION 04
Frequently asked questions
Can the app clear local storage to fix every upgrade?
Only if the cleared data is genuinely disposable and the behavior is approved. Do not erase unsynced drafts or evidence as an undocumented shortcut.
Do we need to test users who skipped updates?
Yes, for the prior versions the product supports. The latest-to-latest path alone may not cover actual installed devices.
Is backup restore the same as app update?
No. Restore can introduce older data, device-specific values or different account state. Test it as a separate lifecycle case.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Database migration testingAndroid Developers
- App backup and restore rulesAndroid Developers
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy