A practical decision guide
Software migration checklist
A new subscription is only the start of a switch. Check what must move, rehearse with a sample and decide how the team will recover before changing the live workflow.
1. Inventory the work that must move
Name the current system, the target plan and the person responsible for each part of the move. List records, files, relationships, permissions, automations, integrations and reports. Ask users which saved views and informal workarounds they depend on.
Decide what to migrate, what to archive and what to leave behind. Keep the decision and its owner beside each item. Separate the deadline for your operational move from any subscription notice or renewal date you need to confirm.
| Item | Question to settle | Evidence to keep |
|---|---|---|
| Records and identifiers | Which fields and links must remain usable? | Sample export, field mapping and expected counts. |
| Attachments and history | Are files, comments and timestamps included? | Opened files and a list of exclusions. |
| Roles and ownership | Who should see, change and administer each area? | Role mapping and permission test results. |
| Integrations and automations | Which connections need new credentials or rules? | Named owner, test and recovery steps. |
| Reports and saved views | Which outputs are needed on the first working day? | Example output and the target equivalent. |
2. Rehearse an export and import
Use a non-sensitive representative sample before attempting a full move. Include unusual field values, an attachment, a duplicate, an archived item and linked records where your workflow uses them. Preserve an untouched export and record the steps needed to create it.
Import the sample into the target and reconcile the result. Counts are a useful first check, but matching counts do not prove that relationships, dates, text or permissions survived. Open a few linked records and recreate a task using the imported data.
Document every transformation and exclusion. If the target cannot represent an old field, decide how the information will remain accessible and who accepts the compromise. Treat an export button as the start of this test, not as proof of a complete exit.
3. Rehearse the workflow and access
Ask a regular team member to complete the important daily task with the imported sample. Test as the roles you will actually assign. Check both that an authorised user can act and that a restricted user cannot see or change the wrong information.
Rebuild one integration or automation end to end. Record field mapping, duplicate handling, notifications and the person who receives errors. If you must run both systems temporarily, define which one is the source of truth for each type of record.
Have a second administrator follow the handover notes. Unwritten setup knowledge is a migration dependency just as much as a file or connector. Capture what they needed to ask before the cutover date.
Use the pilot acceptance tests4. Write the cutover and rollback conditions
Create an ordered runbook: who starts the change, when writes to the old system stop, how the final changes are transferred and which checks must pass before normal work resumes. Include the communication to the team and a named person who can pause the move.
Set rollback conditions before starting, such as an essential workflow that cannot complete or a reconciliation check that fails. Write down the last point at which returning is straightforward and how any new records in the target would be preserved.
A backup alone does not establish that you can recover within the time available. Rehearse the recovery steps on your test sample and confirm access to the required accounts and files. Adjust the runbook to what the rehearsal showed.
5. Review the first working period before retiring the old tool
Assign an owner to collect issues and distinguish missing data, configuration problems and training needs. Re-run the essential tests with the team and resolve or explicitly accept each remaining issue.
Confirm that exports and retained records can still be read without relying on the old live workflow. Follow the retention and deletion requirements your organisation has established; this checklist does not set those rules for you.
Verify the old contract’s notice, renewal and access terms before cancelling it. Count overlap and migration work in the cost comparison. Close the change only when the handover, remaining access and ongoing ownership are documented.
Include migration in the software cost estimateYour decision checklist
Checkmarks stay on this page only. Use your browser’s print command to keep a copy.
Common questions
Is a CSV export enough for a migration?
It may carry the tabular records you need, but inspect the actual export. Files, relationships, permissions and history need their own checks. Test whether the target can reconstruct the workflow from what is included.
Should both systems run at the same time?
That depends on the workflow and the cost of interruption. If you plan an overlap, define where new work belongs and how you will reconcile changes. Two writable copies without ownership can leave the team unsure which is current.
When is it safe to retire the old tool?
Use the acceptance and retention requirements you agreed for the move. Complete the workflow checks, confirm readable retained data and review contract terms before closing access. A successful login to the new tool is only one check.