Most data loss during a software switch isn't dramatic. Nothing gets deleted; things simply arrive incomplete — the notes attached to a contact don't come across, closed tickets lose their conversation history, custom fields land in one merged blob — and nobody notices until someone needs the record months later.
The fix is sequencing. A migration run as a single "move everything this weekend" event depends on everything working the first time. Run in stages, each with a clear exit test, and every failure surfaces while it's still cheap to fix. This guide lays out seven stages, what to do in each, and the check that tells you it's safe to move on. It picks up where the software buying process leaves off, and applies to any category — CRM, help desk, email marketing, or project management.
Stage 1: Audit what you actually have
Before touching an export button, find out what you're moving. Most teams overestimate how much data matters and underestimate how much of it is entangled with other systems.
List each type of record and, next to it, who needs it and for how long: contacts, companies, deals or tickets, conversation history, attachments, notes, tags, custom fields, automations, templates, reports, and user accounts with their permissions. Then mark each one as must move, nice to have, or archive only.
That last category is the one that saves you. Historical records you'll never edit again don't need to live in the new tool — a clean export stored somewhere safe is often better, cheaper, and faster than a lossy import.
Exit test: you can name every record type in the old tool and say where it's going.
Stage 2: Prove you can export — before you commit
This is the stage that gets skipped, and it's the only one that can save you from a trap. Run a real export from your current tool early, ideally while you're still trialling the new one.
Check three things about the file you get back:
- Completeness. Does it include attachments, notes, and conversation history, or only the top-level records? Many exports quietly drop the child records.
- Format. Is it something a new tool can read, or a proprietary archive?
- Limits. Are there caps on rows, date ranges, or exports per month? Is it self-service or a support request with a queue?
If your current vendor makes leaving hard, you need to know that now, because it changes the plan and sometimes the timing. And when you evaluate the new tool, ask the same question in reverse — every purchase is also a future exit, which is why export terms belong in the total cost picture rather than in the fine print.
Exit test: you're holding a real export file from the old system and you've opened it.
Stage 3: Map the fields and clean the data
Fields rarely line up one to one. The old tool's single "Notes" field may be three fields in the new one; a status list may have values with no equivalent; a phone field may accept formats the new tool rejects.
Build a simple mapping sheet: old field, new field, transformation needed, and what happens to values that don't fit. Anything with no destination is a decision, not an accident — decide consciously whether it's merged, dropped, or archived.
Then clean before importing, not after. Duplicates, dead contacts, unsubscribed addresses, and test records are far easier to remove from a spreadsheet than from a live system, and importing them means paying to store and sort them later — the per-record cost is real on tools priced by contact or usage.
| What you're moving | What usually breaks | What to do about it |
|---|---|---|
| Contacts and companies | Duplicates merge badly; relationships between records get flattened | Deduplicate before import; check a few linked records after |
| Conversation or ticket history | Threads import as single blobs, or timestamps reset | Confirm the format in a pilot; archive the originals regardless |
| Attachments and files | Not included in standard exports; size limits | Export separately; verify a sample opens |
| Custom fields | No destination, so values are silently dropped | Map explicitly; decide merge, drop, or archive |
| Tags and segments | Naming rules differ; nested structures flatten | Simplify the taxonomy before you move it |
| Automations and templates | Don't transfer at all between vendors | Rebuild deliberately; treat as a chance to prune |
| Users and permissions | Roles don't match; everyone lands as admin | Re-set permissions manually at cutover |
Stage 4: Pilot import a small slice
Import a representative sample — not your easiest records, and not all of them. A few hundred contacts including the messy ones, a handful of tickets with long histories and attachments, one live project with its real complexity.
Then verify by reading, not by counting. Row counts matching proves almost nothing. Open several records and check that notes are attached to the right people, dates read correctly, links between records survived, and nothing landed in the wrong field.
Do this during the trial if you possibly can. A mapping problem found in a trial is a finding; the same problem found after you've paid and announced a launch date is an incident.
Exit test: you've manually inspected a sample of imported records and they're right.
Stage 5: Run both systems in parallel — briefly
For anything customer-facing or time-critical — support queues, live pipelines, scheduled campaigns — overlap the old and new tools for a short, defined window rather than cutting over cold.
Keep the parallel period short and rule-bound. Two systems accepting new data with no rules is how records diverge and how the team loses trust in both. Decide up front:
- Which system is the source of truth during the overlap (usually the new one, with the old one read-only).
- Where new work goes, with no exceptions.
- How long the overlap lasts, as a date.
A read-only incumbent gives you a safety net without letting the data fork. If you can't make it read-only, keep the window as short as you can stand.
Exit test: the team has done real work in the new tool for a full cycle without falling back.
Stage 6: Cut over deliberately
Cutover is a scheduled event, not a drift. Pick a genuinely quiet week — not month-end, not your busy season, not the week two key people are away — and work a short checklist:
- Run a final delta import for records created or changed since the pilot.
- Switch the integrations: forms, website embeds, calendars, email sending domains, chat widgets, and anything that writes into the old tool.
- Redirect the inbound paths — the support address, the signup form, the shared inbox rules.
- Set permissions properly in the new tool, replacing whatever the import produced.
- Announce the switch internally with the date, the new location, and where the archive lives.
- Make the old tool read-only on a stated date.
The integration step is the one that bites. Data usually moves fine; it's the form still posting to the old CRM, or the alias still routing to the old help desk, that keeps a dead system quietly alive for months.
Exit test: nothing new is being created in the old tool.
Stage 7: Decommission — and don't cancel too early
Resist cancelling the old subscription the moment cutover completes. Keep it, in the cheapest available state, until you're confident nothing is missing — one full billing or reporting cycle is a reasonable minimum, longer if your work has seasonal patterns.
Before you close the account:
- Take a final full export and store it somewhere durable that isn't the new tool.
- Confirm any records you're legally or contractually required to retain are in that archive.
- Note the auto-renewal date and notice window so cancelling doesn't collide with a renewal you forgot about.
- Revoke integrations and API keys rather than just abandoning them.
Then run a short retrospective while it's fresh: what didn't come across, what you'd map differently, and what you'd ask the next vendor about exports. That note is worth a lot the next time you switch — and treating switching as inevitable is one of the habits that prevents the common buying mistakes that lock teams into tools they've outgrown.
What to decide before you start
- Is the switch worth it? Migration costs real hours. If the current tool is merely annoying rather than blocking, the honest answer is sometimes "not yet."
- Who owns it? One named person, with time allocated. Migrations without an owner stall at stage 3.
- What's the archive strategy? Decide early what lives in the new tool and what lives in cold storage.
- When is the quiet week? Book cutover backwards from that date.
FAQ
How do I move to a new CRM without losing my data?
Work in stages: audit what you have, test the export from your current CRM before committing, map fields and clean the data, pilot-import a representative sample and inspect records by hand, run the old system read-only alongside the new one briefly, then cut over in a quiet week and keep the old account until you're sure nothing's missing. The single highest-value step is the early export test, because it reveals limits while you can still change plans.
What data usually doesn't survive a software migration?
Attachments, conversation history, custom fields with no destination, nested tags, and anything built rather than stored — automations, workflows, templates, reports, and permissions. Records themselves usually move; their context often doesn't. Assume built configuration will be rebuilt by hand and plan the time for it.
How long should I run the old and new tools in parallel?
Long enough for the team to complete a full working cycle in the new tool, and short enough that data doesn't fork — set an end date before you start. Making the old tool read-only during the overlap gives you the safety net without the divergence.
Should I import all my historical data?
Usually not. Historical records you'll never edit again are often better kept as a clean export in durable storage than imported into a tool that charges by record and sorts them into your daily views. Import what you'll act on; archive the rest deliberately.
When is the best time to switch business software?
Your quietest predictable stretch, with the owner and the daily users present, and away from renewal dates on either side. Avoid month-end, seasonal peaks, and weeks when key people are away — the migration itself is rarely the problem, but recovering from a surprise during a busy week is.
Compare before you commit
The best time to think about migration is before you buy, because the tool you're leaving and the tool you're joining are governed by the same question: how easily can you get your data out? Weigh that alongside features and price, and treat a clean export path as a feature in its own right.
When you're weighing finalists, line them up against a scored comparison on Bettaso — our email marketing, CRM, help desk, and project management pages lay out the criteria, the trade-offs, and the Bettaso pick for each category. (Bettaso earns affiliate commissions when you buy through our comparisons; it never changes the scores or the order.)
