How to Move Users and Data When Rebuilding a Mobile App

A new app can look right while the customer loses everything

Imagine a runner opening a redesigned training app after an update. The navigation is cleaner, but last month's routes and saved goals have vanished. From the company's perspective, the rebuild shipped. From the customer's perspective, the product broke. The same problem is sharper for a booking app if a paid reservation disappears, or a travel app if a ticket no longer opens at the gate. The examples in this guide are illustrative, not reports of Appfyl client incidents.

Migration is the work of preserving the right relationship between a person and their data while the app, backend or provider changes. It is not the same as copying every database row. Start by deciding what the customer must still be able to do on the first morning after release. The app redesign guide covers the wider product decision; this article deals specifically with continuity of accounts, records and access.

Identify which kind of change you are making

An update to the existing app, a new app published under a different store identity, a replacement backend and a change of company account are different projects. Do not assume that installing a visually similar new app will preserve the old app's local storage or sign-in session. Ask the current owner who controls the App Store and Play Console listings, signing credentials, backend, domains and user database. Record the answers before anyone promises a seamless update.

Some products can release a new interface through the existing listing while keeping their current services. Others have to move accounts between systems. In the second case, the transition may affect login, purchases, push tokens, deep links and the older versions still installed on people's phones. Write down which parts truly change. A redesign that only changes presentation should not acquire an unnecessary data migration just because a new team prefers a different backend.

Map the data people expect to keep

Hold a short workshop with product, support and engineering. For each user-visible item, note its current source, owner and destination. The most dangerous omissions are often outside the main database: an entitlement held by a billing provider, an unsent draft stored only on the device or an appointment in a separate scheduling tool.

Do not use an email address as the sole matching key without checking duplicates, changed addresses and social sign-in. A customer's current account may have several identifiers, while an old system may contain two records for the same person. The mapping needs an explicit rule for those cases and a way to reverse an incorrect merge. Sensitive data should not be exported casually into a spreadsheet simply because it makes the workshop easier.

Decide what to clean, merge and leave behind

Old data is rarely uniform. A class-booking app may contain cancelled lessons still shown as future bookings, duplicate customer profiles and dates saved without a time zone. If you import those records unchanged, the new product will inherit the confusion. If you silently discard them, support may lose the evidence needed to resolve disputes. Classify each field as required for the new service, required only for support or history, or unnecessary to move.

Take a small sample of real shapes of data, anonymise it and write a rule for each exception. For a booking, that could mean converting a stored local time to an unambiguous time zone, preserving whether the booking is paid, and linking any refund to the original transaction. For a training app, a route with missing coordinates may still deserve a dated history entry rather than disappearing. Make the choice visible to product and support, not only to the person writing the import script.

This is also a moment to check retention and deletion obligations with the relevant legal owner. A technical ability to copy data is not permission to keep it forever. The handover checklist helps establish who controls the exports and how another team could restore service later.

Rehearse on a copy before touching production

A rehearsal should use a protected copy of representative data, including awkward records, and a new environment that behaves like the intended release. Do not start by moving only ten perfectly clean test users. Compare source and destination counts by record type, then inspect a sample of complete user journeys: can the person sign in, see an old booking, use a current entitlement and contact support about an earlier purchase?

Counts alone do not prove correctness. One duplicated account and one missing paid booking can cancel each other out in a total. Keep a migration report with unmatched identities, records rejected by validation, duplicate candidates and manual decisions. Record enough identifiers to reconcile a case securely, without publishing customer data in a general project chat.

Platform tools can help, but their limitations matter. Firebase Authentication's import guide notes that its bulk import does not check every identifier for duplicates; the team must prepare and inspect its input. Cloud Firestore's export/import guide explains that a managed export is not an exact snapshot of the database at the instant the export starts. These are examples for products using Firebase, not reasons to move an unrelated app to Firebase.

Plan the changeover and the way back

The hardest question is what happens while people continue using the old app. You might briefly pause writes, run a final import and reopen the service. Or both systems may need to accept changes for a controlled overlap. The second option is harder: decide which system is authoritative and how to resolve conflicting edits. A vague promise of "syncing" is not a cutover plan.

Agree on a release window, a person with authority to pause it, a backup and a point at which rollback stops being simple. If new users have already created records in the new system, returning to the old one without losing those records is not automatic. Rehearse rollback as seriously as migration. Decide whether old app versions can still connect and what message they show if they cannot. For an app that stores drafts or tickets locally, test upgrading from more than just the immediately previous version; users often skip updates.

Both stores have controlled release mechanisms, but they do not replace data planning. Apple describes phased app updates, while Google Play documents testing tracks and staged production releases. These mechanisms can limit exposure while the team watches failures. They cannot undo a destructive database import or guarantee that every user updates in a fixed order.

Test continuity as a user, not as a database administrator

Write a small acceptance set before launch. A long-time customer signs in on the updated app and finds the same active booking. A customer who changed email can recover the correct account without being given someone else's data. A paid subscriber retains valid access after changing phones. A cancelled booking remains cancelled. A support agent can explain why a historical balance changed. If any of these are core to the product, the release is not ready until the team can demonstrate them on the actual build.

Include failures: wrong password, expired session, unavailable old service, partial import, duplicate identity, no network and a person who installed a much older app version. The pre-launch QA guide helps turn those cases into a repeatable test. Watch login failures, missing-record tickets, crashes and drop-off in the first key action during rollout; do not treat the number of imported rows as the only success metric.

Customer communication matters as much as the script. Tell people if they must update, sign in again or take action to keep device-only drafts. Do not promise "nothing changes" when the login or offline behaviour will change. Give support a lookup procedure and a way to escalate a missing paid entitlement immediately. For many users, confidence comes from receiving a clear answer when something seems wrong, not from a silent technical success.

What to put in the project brief

Bring the current app, store listing, account provider, database owner and a sample of important user journeys to the first discussion. Note what must be preserved, what can be archived and which old versions still have users. Ask the delivery team for a rehearsal plan, reconciliation report, release gate and rollback conditions. That is more useful than requesting a "complete rewrite" without specifying what existing customers would lose.

The project may ultimately need a new backend, or it may not. Appfyl can use a short project brief to understand the scope, then examine the migration risks with the appropriate technical owners. The aim is continuity that can be verified, not a promise that every record will move perfectly on the first attempt.

Questions people ask