Migrating off a tool you have outgrown, without losing your data

Migrations rarely fail at the import step. Imports are boring and mostly work. What fails is everything that never made it into the export file, discovered four months later when someone needs the thing that is no longer anywhere.

The fix is not a better tool. It is doing the steps in an order that puts the discovery early, while you still have a live account in the system you are leaving.

What an export usually leaves behind

• Attachments. Very often a link to a file that stops resolving the day the account closes.
• Comment threads and their authors. Frequently flattened into one text field, or dropped entirely.
• Timestamps. Created and updated dates commonly become the import date, which silently destroys any history you might have wanted to report on.
• Custom fields. The values export; the definitions, the pick lists and the validation do not.
• Relations. Parent tasks, linked deals, merged contacts, dependencies — the graph is usually the first thing to go.
• Archived and deleted items. Often outside the export by default, and sometimes the only copy of a decision.
• Automations and workflows. Never exportable. Screenshot them before you cancel.
• Permissions and groups, and any audit log.

Do the export before you decide, not after

Run a full export from your current tool while you are still evaluating replacements. It takes an hour, it tells you what is actually portable, and it occasionally changes the decision — a tool you can leave cleanly is worth more than a tool with one extra feature.

The order of operations

1. Inventory what lives there. Not just records: reports people rely on, links pasted into other systems, email addresses that route into the tool, dashboards on a wall screen.
2. Export everything and open the files. All of them. A ZIP you did not unpack is not a backup.
3. Separate live data from history. Live data has to migrate perfectly. History usually only has to be findable, and a read-only archive is often cheaper and safer than importing five years of closed records.
4. Agree a freeze window and tell everyone the date, in writing, twice.
5. Dry run into a sandbox on the new tool. Import, look at ten records, throw it away, fix the mapping, do it again.
6. Reconcile with counts before you announce success. See below.
7. Cut over at a quiet boundary — the start of a month, never the last week of a quarter.
8. Keep the old account read-only for at least one full business cycle. This is the cheapest insurance in the whole project.

Reconcile with counts, not with vibes

Before and after, count the same things: records per type, per owner, per status. Check that the oldest and newest record in each set match. Then open five records at random and compare them field by field with the source. This takes half an hour and catches the class of failure where the import "worked" and quietly dropped every record with an empty required field.

The integrations are the hidden work

• Webhooks and API keys pointing at the old system, including ones written by someone who has left.
• Links to old records embedded in other tools, wiki pages and email signatures.
• Saved reports and dashboards that other people rely on but never mentioned.
• Forms on your website that post into the old tool.
• SSO application assignments and any provisioning rules.
• Calendar and mail sync, which usually needs disconnecting before it will reconnect elsewhere.

What you have to keep, and what you must not

Two obligations pull in opposite directions. Accounting documents, contracts and employment records have statutory retention periods, and "we changed systems" is not a defence for not having them. At the same time, the GDPR does not let you keep personal data indefinitely because it was easier than deciding. Handle both by deciding retention per data type at migration time — it is the only moment when someone is looking at all of it anyway.

A migration is the only time anybody reads the whole dataset. Use it to throw things away deliberately, because you will not get another chance for years.

Closing the old account properly

1. Check the notice period and the auto-renewal date before you cancel anything. Many annual contracts renew silently with a notice window measured in weeks.
2. Download the final invoices and the contract itself.
3. Revoke API keys and tokens, and remove the app from your SSO.
4. Ask for written confirmation of deletion, including backups, and check what your data processing agreement says the timeline is.
5. Only then close the account.

When not to migrate

If the complaint is "nobody updates it", "we cannot find anything" or "the reports are wrong", the problem is probably process rather than software, and a migration will relocate it at some cost. Work tools in particular tend to absorb the blame for missing agreements about how a team works. Asana, monday.com and ClickUp are all capable of running the same team well or badly, and moving between them changes nothing if the conventions do not change too.

If the complaint is about limits, price steps, permissions or an integration that does not exist, that is a real reason to move. And if you are leaving a CRM specifically, export contacts, notes, files and deal history separately and check each one — a HubSpot or any other contact export that omits the notes is a very common surprise.