Migrating off a CRM without losing your pipeline history

The pipeline history is the part people forget until it's gone. Contacts move fine. Companies move fine. Then a rep goes looking for the note that explains why a $400,000 deal stalled in 2023, and it isn't there. That's the moment a CRM migration turns from a project into a crisis.

Moving off a CRM is mostly a data problem, and data problems are solvable. But they're solvable in a specific order, with a specific amount of paranoia. Here's how to do it without torching eight years of institutional memory.

Export everything twice, audit it before you load it, and run both systems side by side for a full sales cycle. Attachments, activity history, and record relationships are the three things that break during a CRM migration, and none of them come out cleanly with a standard CSV export. Keep read-only access to the old system for at least a quarter after you go live, and time your contract cancellation around that, not around your go-live date.

• Activity history and attachments need a scripted export through the platform's API, because the built-in export buttons either skip them or flatten them into unusable text.
• Record relationships (which note belongs to which deal, which deal belongs to which account) are stored as ID numbers. If you don't carry those IDs across, you get orphaned data.
• A migration is the only time anyone will agree to delete dead records, so use the window to clean house.
• Run the old CRM in read-only mode during the parallel period. Two writable systems means two versions of the truth.
• Sales adoption fails on reporting parity more than on training. If a manager can't rebuild their weekly forecast on day one, the new system gets blamed.
• Budget for the fact that some things do not migrate. Email threads synced from a mailbox plugin usually stay behind.

Start by listing the objects, which is just a fancy word for record types. Most CRMs have the same core set. Contacts, accounts or companies, opportunities or deals, activities (calls, emails, notes, tasks), attachments, and whatever custom fields your team bolted on over the years.

The objects are easy. The relationships between them are where migrations die. Every note in your CRM is attached to a record by an internal ID number, not by a name. When you export a note to a spreadsheet, you often get the note text and a date, and a column of ID numbers that mean nothing outside the old system.

So your export plan has to carry the old ID for every record, and your import plan has to keep a lookup table mapping old IDs to new ones. Do that and the notes land on the right deals. Skip it and you get 60,000 notes floating in space.

Also decide what you're deliberately leaving behind. Closed-lost deals from 2016 with no notes attached are not history. They're noise. Nobody has opened them and nobody will.

Every platform has an export button, and every export button lies a little. Here's what actually goes wrong.

Attachments are the worst offender. Most CRMs will export a spreadsheet row that contains a link to a file, not the file itself. Click the link after you cancel the subscription and you get a login screen for an account that no longer exists. Pulling the real files means hitting the platform's API, which is the programmatic back door that developers use, and downloading each one. On a mid-sized CRM that can be tens of thousands of files.

API rate limits are the second problem. Platforms cap how many requests you can make per hour or per day. Salesforce, HubSpot, Zoho and Dynamics all do this in different ways. A large attachment pull can take days of running a script that pauses, waits, and resumes. That's fine, but you need to know it before you promise a go-live date.

Then there are the fields that look fine and aren't. Multi-select picklists export as a single text cell with semicolon-separated values. Rich text notes export with HTML markup baked into the cell. Formula fields export their calculated result, not the formula, which is usually what you want but occasionally not. Currency fields lose their currency code. Time zones shift on date fields more often than anyone admits.

Email history is the one that surprises people. If your reps use a mailbox sync plugin, the emails often live in the plugin's own storage, not in the CRM's exportable data. Check this early. The answer is sometimes "those threads stay in Outlook," and that's survivable as long as you know in advance.

Pull the export into a spreadsheet and look at it honestly. You will find duplicates. You will find three versions of your biggest customer with slightly different spellings. You'll find custom fields created in 2019 for a campaign that ran once, now sitting empty on 40,000 records.

This is the only moment your sales team will tolerate a cleanup. Once the new system is live, nobody wants to touch data hygiene again. So do it now.

A practical audit covers a few things. Count how many records have a value in each field, and delete any field where the fill rate is under a couple of percent. Find duplicate accounts by domain name rather than company name, because "Acme Inc" and "Acme, Inc." are the same company and a machine won't know that. Identify contacts with no email, no phone, and no activity in three years, and decide as a group whether they move.

Have the sales manager sign off on the deletions in writing. Not because anyone's being difficult, but because six months later somebody will ask where the 2018 leads went and you want a document, not a memory.

The parallel run is where most of the risk gets managed. The rule is simple. One system takes writes, the other goes read-only.

Set a cutover date. From that morning, all new activity goes into the new system. The old CRM stays accessible so people can look things up, but you strip edit permissions from everyone. If two systems accept edits at once, you end up with a deal that's at 60 percent in one place and closed-won in the other, and no way to know which is right.

Run the read-only period for at least one full sales cycle. If your average deal takes four months to close, three weeks of parallel access isn't enough. Reps will go back to the old system to find context on deals that were already in flight during the switch.

During this window, keep a shared log of anything anyone couldn't find. That log becomes your punch list. Usually it's a handful of fixable gaps, like a custom field that didn't map or attachments on one object type that got missed.

Adoption fails for reasons that have nothing to do with software quality. The two big ones are field names and reporting.

Name fields the way your reps talk. If everyone in the building says "job number," don't call it "Project Reference ID" because that's what the old system called it. Migration is your free chance to fix a decade of bad labels. Take it.

Reporting parity matters more than features. On day one, every report a manager runs on Monday morning needs to exist and produce the same numbers as the old system did the Friday before. If the forecast total differs by even a little, trust evaporates and people go back to spreadsheets. Build those reports during the parallel run and reconcile them against the old CRM until they match exactly.

Train in short sessions on real records, not demo data. A rep learns faster looking at their own pipeline than at fictional deals for a fake company. And pick two or three people who learn it first and become the ones everyone asks. That works better than a help desk.

Certain integrations fail almost every time, and knowing the list in advance makes it a checklist instead of a fire.

• Email sync. Every rep has to reconnect their mailbox individually, and some will need IT help with permissions. Do this before go-live, not on the day.
• Calendar integration. Meetings booked in the old system won't carry their CRM link. Existing calendar invites survive, but the connection to the deal record doesn't.
• Quoting and proposals. If quotes were generated from CRM data, the templates need rebuilding against new field names. Rebuild them first, because a rep who can't send a quote is blocked from selling.
• Web form routing. Forms on your website post to the old CRM's endpoint. Re-point them and test with a real submission before you switch.
• Marketing automation handoff. Lists, scores, and enrollment status often don't map cleanly between platforms.

Sequence it by what blocks revenue. Quoting first, then email sync, then web forms, then reporting, then the nice-to-haves. Nobody loses a deal because dashboard colors are wrong.

Not every migration is worth doing, and not everything survives the trip. A few realities worth saying plainly.

Some data legitimately cannot move. Platform-specific features like proprietary lead scores, engagement timelines, or AI-generated summaries exist only inside that vendor's system. You can export the number. You can't export the logic that produced it.

Migrations cost real effort even when they go well. Between the export scripting, the audit, the parallel run, and the training, you're looking at meaningful time from your operations lead and your sales manager. That's a genuine cost, and it's worth weighing against staying put.

The arithmetic is usually what settles it. Take 45 seats at $165 per user per month. That's about $89,000 a year, forever, rising at renewal. If your team uses maybe a third of what the platform does, and the pain is mostly that you can't change anything without paying for a new tier, a system you own outright stops that meter. If instead your team uses the platform hard and the price feels fair, don't migrate for the sake of it.

Work through this before anyone touches a production import.

1. Take a complete raw export of every object, including a separate attachment pull, and store it somewhere outside both systems.
2. Confirm your contract end date and the exact date your data access is revoked. Those are often different, and vendors are not obligated to remind you.
3. Negotiate a short read-only extension if you can. Many vendors will grant a month or two at reduced cost rather than lose the renewal conversation entirely.
4. Document every integration currently pointed at the CRM, including the obscure one finance built three years ago.
5. Get written sign-off on what's being deleted and what's being archived.
6. Build and reconcile the core reports before cutover, not after.
7. Schedule the cutover for the start of a month, never the end of a quarter.

Do these seven things and the migration becomes boring. Boring is the goal.

How long does a CRM migration usually take?

It depends far more on data volume and integration count than on the new platform. A clean CRM with 20,000 records and two integrations is a different job from one with 400,000 records, twelve custom objects, and a quoting engine. Scope the export first, then estimate.

Can we keep our old CRM data without keeping the subscription?

Yes, if you export properly before access ends. The data is yours. What you lose is the interface for browsing it. Many teams load the raw archive into a simple searchable database so old records stay findable without paying for seats.

What happens to emails synced into the old CRM?

Usually they stay in the mailbox they came from, which means Outlook or Gmail still has them. The CRM's copy of the thread often can't be exported in a usable format. Check this specifically with your platform before you assume either way.

Should we clean the data before or after we move it?

Before. Loading garbage into a new system and promising to fix it later never happens. The cleanup is easier in a spreadsheet than in a live CRM anyway.

Is it safe to cancel the old subscription on go-live day?

No. Keep it for at least a full sales cycle in read-only mode. The moment you cancel, you lose the ability to check anything you missed, and you will have missed something.

If you're staring at a renewal notice and wondering whether this is the year you stop paying per seat, run the export audit first. It tells you how hard the move actually is, and it costs you nothing but a few hours. From there the decision usually makes itself.

When you want a second set of eyes on the plan, book a free strategy session and we'll walk through your data and your integration list with you.

Read this next: our breakdown of what it really costs to own your software instead of renting it.

Related articles

• Why per-seat pricing punishes growing teams
• Integrating a custom system with QuickBooks and Outlook
• How to scope a replacement for software you've outgrown