How to Switch Software Without Losing Important Data

To switch software safely, export a recoverable copy, test a small import, compare what arrived, and keep the old system available until the new workflow is proven. A successful import message is not enough: you need to check the meaning and usefulness of the imported data.

This checklist applies to moving between project tools, document systems, catalogues and other business apps. Exact export formats and retention periods vary by vendor, so verify those details in the current documentation for your plans.

Inventory what must survive

List the important information rather than only counting files. A project may include attachments, dates, owners, status values, links between records, comments and permissions. Decide which must remain editable, which only needs to be archived, and which can be discarded.

Record a few totals from the old app: active projects, records by status, attachments and user groups. These become useful comparison points after the move. Keep the inventory somewhere independent of the app being replaced.

Export while you still have access

Create a backup before changing the source data. If the app offers several export formats, retain both its fullest native export and a commonly readable format when practical. Keep accompanying attachments and any notes explaining field meanings.

Open a sample of the exported files. An export is not a tested backup until you have established how you would read or restore the information. Keep a separate unchanged copy; do all cleanup work on a duplicate.

Build a field map

Map old fields to new ones explicitly. “Owner” could mean a person in one tool and a team in another. Dates may have different formats or time zones. An identifier such as 00123 should not become 123 if those are distinct records.

Document exceptions. Do not silently replace an unknown value with a convenient default.

Import a small, awkward sample

Use a sample that includes normal records and the cases most likely to break: long names, special characters, empty values, attachments and cross-linked records. Inspect the result with someone who actually uses the information.

Check counts, totals where meaningful, relationships and permissions. Open attachments rather than merely checking that filenames appear. Test whether a restricted user can see only what they should. Correct the mapping before a larger import.

If CSV is involved, read our CSV import checklist. CSV parsing issues and application-specific field rules are different problems.

Plan the final handover

Choose a short period in which changes to the old system stop or are recorded for transfer. Otherwise, work created during the move can fall between the two systems.

Write down who performs the export, who validates it and who decides whether to proceed. Define a rollback condition, such as missing essential attachments or incorrect permissions. The rollback plan should explain where new work is recorded if you return to the old system.

Retire the old tool deliberately

Do not cancel the old subscription merely because the first import finished. Confirm that the required exports are stored safely, everyday work succeeds and the team knows the new process. Then review the old vendor's access, deletion and retention rules before cancelling.

Can CSV move an entire project?

Sometimes it can move the records you need, but a flat table may omit comments, attachments, permissions or relationships. Inspect the actual export and the destination's import specification.

Is matching the record count enough?

No. Equal counts can conceal changed identifiers, shifted dates, duplicate records or broken links. Compare representative content and relationships too.

Should I delete old data immediately?

Keep only what your obligations and policies permit, but avoid irreversible deletion before validating the migration and backup. Agree the retention decision with whoever owns that information.

Keep a reconciliation sheet

For a small synthetic sample, record the original identifier, expected destination and the observed result. An identifier such as 00123 must remain the same identifier if its leading zeros are meaningful. A successfully imported row with the wrong relationship is still a failed test.

If the handoff is an ordinary folder archive rather than application records, the archive handoff checklist covers naming decisions, separate copies and a path map. A local preparation tool is not a replacement for a destination-specific migration or permission review.