TH The App Exit Test
Data Moves

Migrate App Data Without Losing the Original

The App Exit Test · Updated 2026-07-19 · 4 min read
Migrate App Data Without Losing the Original
tldrMigrate app data by inventorying records, attachments, structure, permissions, integrations, and retention requirements; preserving an independent export; and importing a pilot into an isolated destination. Map every field, reconcile counts by record type, open files, test search and permissions, and assign every exception. Move in batches with a documented stop and rollback plan, capture changes made during migration, and keep the source intact or read-only through user acceptance. Delete accounts, revoke access, cancel subscriptions, and remove temporary archives only as approved destructive actions after required retention and verification are complete.
Contents

Keep the source intact through verification

Migrate app data safely by inventorying the source, making an independent export and backup, testing a small representative import, reconciling counts and fields, then moving in controlled batches. Keep the original system read-only or otherwise intact until users have tested the destination and every exception has an owner.

Destructive actions come last. Do not delete the source account, revoke a required integration, overwrite the only export, or cancel access needed for verification. A successful progress bar is an event, not a signed affidavit from every attachment.

Inventory what must move

List record types, owners, workspaces, folders, tags, comments, attachments, links, permissions, timestamps, versions, automations, templates, recurring items, integrations, and audit or retention requirements. Record source counts and known anomalies.

Separate active data from material that should be archived, retained for legal or policy reasons, excluded for privacy, or deleted under an approved process. Migration is not permission to copy every historical record into a new processor.

Name the people responsible for security, privacy, compliance, business validation, and user communication where appropriate. Confirm current export and import documentation for the exact source plan and destination version.

Browse data moves for more staged handoff patterns.

Export to an independent location

Request the official export and preserve the original archive unchanged. Save a working copy for transformation. Record export time, account, scope, format, tool version, and any warning or excluded item.

Store files with access controls appropriate to their contents. Exports can be more exposed than the source because they may lack application permissions or encryption. Do not email sensitive archives, place them in a shared personal folder, or upload them to an unapproved converter.

Open the archive and inspect its manifest, folders, files, and encoding. An export that cannot be extracted or read is not a backup merely because its filename contains the word “backup.”

Build a representative pilot

Choose a small set covering simple and difficult cases: long text, non-Latin characters, old and new dates, attachments, duplicates, nested structure, shared records, links, comments, and any custom field. Use a sandbox or isolated destination when available and approved.

Map every source field to a destination field, archive, transformation, or explicit exclusion. Record how identities, time zones, permissions, and links will change. Do not silently put unmatched data into a generic notes field if users or systems need its original meaning.

Run the pilot and save logs or reports. Investigate warnings before scaling.

Visit app decisions when destination limitations reopen the product choice.

Reconcile content and behavior

Compare source and destination counts by record type, not only a grand total. Check missing, duplicated, truncated, or failed items and sample records from every edge category. Open attachments, follow internal links, search known phrases, and compare dates, authors, permissions, and special characters.

Test destination behavior: sync, sharing, notifications, recurring items, exports, and expected integrations. Some features cannot migrate as data and must be rebuilt, replaced, or intentionally retired.

Assign each exception a disposition and owner. Keep a migration ledger with batch, count, errors, decisions, and verifier. “Mostly moved” becomes useful only after the unmoved portion has names.

Plan a reversible cutover

Tell users when the source becomes read-only, where new work begins, what will not migrate, how to report an error, and how long verification lasts. Freeze changes or capture a final delta so records created during migration are not stranded.

Move in batches with checkpoints. Stop when errors exceed the agreed threshold or a critical field fails. Restore or roll back according to the tested plan rather than improvising under deadline.

Use our app trial guide to verify the destination's export before it becomes the new source of truth.

Retire only after separate approval

After acceptance, retain the source and exports for the approved period. Confirm legal, contractual, privacy, security, tax, and organizational requirements with qualified owners.

Destructive step: account deletion, source data deletion, access revocation, and subscription cancellation may be irreversible or may start retention clocks. Treat each as a separate approved task. Verify the target account, capture required evidence, and understand the provider's current process before acting.

Remove migration archives from temporary locations under the approved retention plan and revoke temporary credentials. The migration is finished when the destination works, exceptions are resolved, rollback is no longer required, and retirement has been authorized—not when the new logo first appears on everyone's phone.

FAQ

What should I back up before migrating apps?

Preserve an official full export where available, including records, attachments, metadata, structure, permissions, comments, versions, and manifests the provider supplies. Keep the original archive unchanged and make a working copy. Record export date, account, scope, format, and warnings. Store it independently with controls suitable to the data. A folder on the same system, an unread archive, or a synchronized copy without retention may not provide meaningful recovery.

How do I test an app migration?

Import a small representative pilot containing simple and difficult records, old and new dates, long text, non-Latin characters, nested structure, links, comments, attachments, duplicates, and multiple permission levels. Map each field before the run. Then compare counts, open content, search known phrases, verify identities and dates, and test destination behavior. Resolve or assign every warning before scaling to larger batches.

How can I tell whether all data migrated?

Compare source and destination counts by record type, folder, owner, or another meaningful group rather than only a grand total. Review failed-item logs, duplicates, truncation, attachments, permissions, timestamps, links, encoding, and edge-case samples. Test features that may require rebuilding, such as automations and recurring items. Maintain a ledger of batches, counts, exceptions, decisions, and verifiers so the acceptance claim has evidence.

When should the old app become read-only?

Make it read-only at the planned cutover when users have been informed, the pilot has passed, backups exist, and the team knows where new work belongs. If read-only mode is unavailable, define a short freeze or capture a final delta of changes. Do not let both systems accept uncontrolled edits indefinitely. Keep source access long enough for verification and rollback under the approved retention and contract plan.

When is it safe to delete the old app account?

Only after destination acceptance, exception resolution, required retention, tested recovery, and separate approval from relevant data, security, privacy, legal, financial, or business owners. Deletion, cancellation, and credential revocation can have different effects and retention clocks. Verify the exact account and provider process before acting, save required evidence, and remove temporary migration archives under the approved plan. Never delete merely because the import screen reported success.