A Migration Checklist for Switching Software

Switching software is a small project with a large effect on people's working days. Done well, nobody notices except that things get better. Done badly, work stops, data goes missing and the team learns to dread the next change.

This checklist breaks a migration into seven phases, each with concrete tasks. It is meant for individuals, small teams and organisations, and you can scale it up or down.

Why a checklist

Wikipedia describes switching costs as including uncertainty about performance, the effort of evaluating and setting up a new product, the loss of past investment and the emotional discomfort of leaving something familiar. A checklist attacks several at once. It reduces uncertainty by making the steps visible. It reduces effort by organising it. It protects past investment by insisting on backups and verification. And it reduces discomfort by giving people time and information.

Phase 1: Decide

Before anything else, be sure that you want to switch, and why.

• Write the reason. Price, features, trust, fit, change of circumstances.
• Write the must-haves. What the new tool must do, no exceptions.
• Write the nice-to-haves.
• Count the full cost of the move: time, training, disruption.
• Choose the new tool after a trial on real work, ideally with a scoring sheet.
• Name an owner for the migration, and a deputy.
• Set a target date and a rollback date, after which you cannot easily go back.

If the reasons are weak, consider staying. If the owner is unclear, the migration will drift.

Phase 2: Prepare

Preparation takes about a third of the effort and prevents most problems.

• List what you have. Data types, volumes, users, workflows, integrations, automations, templates, settings.
• Decide what to move. Not everything needs to come along. Archive or delete what you no longer use.
• Clean up first. Merge duplicates, fix obvious errors and remove junk. Moving rubbish is wasteful.
• Map old to new. For each type of data and each workflow, write where it will live in the new tool, and note gaps.
• Check exports and imports. Find out what formats the old tool exports and the new tool imports, and what will not carry over. The ICO explains that the right to data portability lets individuals obtain and reuse their personal data across services in structured, commonly used, machine-readable formats. If your data includes personal data, check how this applies and what you must do for the people concerned.
• Plan integrations. List every connection to other tools and decide how each will be rebuilt.
• Check access and permissions. Who needs what in the new tool?
• Prepare people. Tell them what is changing, why and when. Offer training or guides.

Phase 3: Back up

Never begin without a safe copy.

• Export everything from the old tool, in the most complete format available.
• Store the export securely in at least two places, with access limited to those who need it.
• Verify the backup. Open it. Check counts and a sample of records.
• Record the date and the version of the tool.
• Note anything not exported, such as comments, history or attachments, and decide whether to capture it another way, such as screenshots or a separate archive.

Exports may contain personal or confidential information, so handle them accordingly and delete temporary copies when no longer needed.

Phase 4: Pilot

A pilot tests the process on a small scale before the big move.

• Choose a small, representative set: a team, a project or a slice of data.
• Import it into a test area or the real new tool.
• Check the result. Compare counts, dates, relationships and attachments. Open a sample of records and compare them with the old tool.
• Test the main workflows. Perform real tasks, not only demonstrations.
• Ask pilot users for feedback. What is confusing? What is missing?
• Record issues and decide how to fix them.
• Adjust the plan. Update the mapping, the instructions and the timeline.

If the pilot reveals a showstopper, pause. A pilot that finds problems has done its job.

Phase 5: Migrate

When the pilot is satisfactory, do the real move.

• Pick a quiet time. Avoid deadlines and busy periods.
• Announce a freeze on changes in the old tool, with a start time.
• Take a fresh export immediately before the freeze ends.
• Import in stages, starting with the most important data, if the tool allows. Monitor progress.
• Rebuild integrations and automations.
• Set permissions.
• Communicate: tell everyone when the new tool is live, where to find help and how to report problems.
• Staff the help route for the first days, so questions are answered quickly.

Keep a log of what you did and when. It will help if something needs to be undone.

Phase 6: Verify

Do not assume that because an import finished, it worked.

• Compare counts. Items, users, projects, attachments.
• Spot-check records, especially ones with special characters, long text, dates and links.
• Check relationships. Do linked items still link? Do tags and categories match?
• Check history, where it matters.
• Test workflows end to end.
• Check notifications and integrations.
• Ask users to check their own data and report anything odd.
• Keep a list of discrepancies and decide which to fix and which to accept.

Allow a defined period for verification, such as two weeks. Keep the old tool available, read-only if possible, so people can compare.

Phase 7: Retire the old tool

Only once you are confident, close the loop.

• Take a final export and store it with your archive.
• Check retention rules. Know what happens to your data when the subscription ends, and how long it stays available.
• Cancel at the right time, after your verification period and before another billing cycle if you are sure. Check notice periods and automatic renewals.
• Remove access and integrations from the old tool.
• Update documentation, links and bookmarks.
• Tell people it is finished.
• Delete data from the old tool if appropriate and permitted, after you are certain you no longer need it.

Afterwards: learn

Hold a short review. Wikipedia describes a retrospective as a meeting held at the end of a project or process to discuss what went well, what could be improved and how to apply those lessons. Ask:

• What went well?
• What surprised us?
• What took longer than expected?
• What would we do differently?
• What are we still missing in the new tool?

Record the answers. They will make the next migration easier, and they will help you decide whether the switch achieved what you hoped.

Common mistakes

1. Skipping the backup.
2. Moving everything, including mess.
3. No pilot.
4. Not telling people.
5. Cutting over at a busy time.
6. Assuming the import worked.
7. Cancelling too soon.
8. Forgetting integrations.
9. No owner.

A worked example

A six-person consultancy decides to move its client records and project notes from an expensive tool to a cheaper one. The owner is the operations manager. They write their reasons, list must-haves and run a two-week trial.

In preparation, they merge forty duplicate contacts and archive three years of closed projects. They map fields and discover that the new tool has no equivalent for one custom field; they decide to store it in notes. They take a full export from the old tool, store it in two places and verify counts. A pilot with one client team reveals that attachments over a certain size do not import, so they plan to move them manually.

On a quiet Friday, they announce a freeze, take a fresh export, import in stages and rebuild their calendar integration. Over the next fortnight, each person checks their own records, and a short list of discrepancies is fixed. They keep the old tool read-only for a month, take a final export and cancel just before renewal. At the review, they note that the pilot saved them from a bad surprise and that more training notes would have helped.

A one-page version

• Decide: reason, must-haves, owner, dates
• Prepare: inventory, clean, map, integrations, people
• Back up: export, store, verify
• Pilot: small set, test, adjust
• Migrate: freeze, import, rebuild, communicate
• Verify: counts, spot checks, workflows
• Retire: final export, cancel, clean up
• Review: lessons

The categories and search pages here help you compare alternatives before you decide, and the submit page starts a listing that makers can fill in with a description and a link to their website.

Special cases worth planning for

Some migrations carry extra risk. If the old tool holds records you are required to keep, such as financial or employment records, confirm retention rules before you delete anything and keep a verified archive. If the tool is used by customers or clients, tell them what will change and when, and give them a contact for problems. If your team works in several time zones, schedule the cut-over so that nobody is left without a working tool overnight. And if the old vendor is slow to supply an export, start the request early, because delays there can derail the whole plan. A few questions answered in advance usually prevent the most stressful surprises.

Frequently asked questions

Can I migrate gradually? Often, by moving one team or project at a time. It reduces risk but prolongs the period of running two tools.

What if the vendor will not give me my data? Ask in writing, explain your rights where relevant and seek advice.

How do I keep people on board? Explain why, train them early and show how the new tool makes their work easier.