Move CRM Data Without Carrying the Old Problems With It

A company moves from one CRM to another over a weekend. The contact export goes in on Saturday, everything looks right on Monday, and the marketing team sends its first newsletter from the new platform on Tuesday. A few hours later the complaints start. The export didn’t include the old system’s unsubscribe list, because unsubscribes were stored as a separate suppression list rather than as a field on the contact. Several thousand people who had opted out just received an email.

When a migration goes wrong, the data has usually arrived. What’s missing is something the old system handled quietly, like suppression, a calculated field, or a workflow that assigned owners, which never made the move because no one had written down that it existed.

We approach a migration as a rebuild with your data in it. The new system gets a data model designed for how you work now, the records are cleaned and mapped onto it, and every rule the old system enforced is either recreated or consciously dropped.

Should you migrate at all?

Sometimes the honest answer is no. If the current platform can do what you need and the problems come from how it was set up, fixing it is usually cheaper and less disruptive than moving. A CRM audit will tell you which situation you’re in.

Migration makes sense when the platform itself is the constraint: it can’t model your sales process, it can’t connect to the systems you depend on, it costs far more than its value, or it’s being retired. It also makes sense when two teams or two merged companies are running separate CRMs and need one.

What a migration has to cover

Discovery

We inventory what’s in the old system: objects, custom fields, pipelines, users, workflows, integrations, email templates, forms, reports and any scripts or plugins. Then we look at how people actually use it, which is never quite the same as how it was configured.

Mapping

Every field that’s coming across gets a destination, a type and a rule. Some map directly. Some need translation, like a free-text “Industry” field going into a dropdown. Some get merged, split or retired. Objects map too, and not always one-to-one. One platform’s “organization” is another’s “company”, and a tag-based system moving into a property-based one needs its tags converted into fields or lists that mean something.

Cleanup and duplicates

Moving dirty data into a clean system just gives you a new system with old problems. Before import, we deduplicate, standardize values, fix associations between contacts and companies, and decide what to leave behind. If the cleanup is large, it becomes its own phase through CRM data cleanup.

Historical records

Not everything needs to move, and the decision should be deliberate. Closed deals from five years ago, notes from reps who left, email engagement history, call recordings, attachments. For each type we agree whether it migrates in full, migrates as a summary, stays in an archive export, or gets dropped. Platform limits matter here. Some systems can’t import historical email activity at all, or can import it only as notes, and it’s better to know that before promising sales their full timeline.

Consent and suppression must survive the move

This is the part we treat as non-negotiable. Every record’s marketing consent status, the source and date of that consent where you have it, unsubscribes, hard bounces, spam complaints and any manual suppression list must arrive in the new platform in a form it actually enforces.

That’s harder than it sounds, because platforms store this differently. One keeps unsubscribes as a contact field, another as a separate list, another per channel with separate email and SMS consent. Klaviyo tracks consent by channel and suppresses profiles from email. HubSpot uses subscription types alongside a separate marketing contact status. A mapping that looks fine in a spreadsheet can still leave the receiving platform treating an opted-out contact as sendable.

So we import suppression data first, check a sample of known unsubscribed and bounced contacts in the new system, and confirm they’re excluded from sends before any campaign or flow goes live. If consent history is incomplete in the old system, we flag it rather than guess.

Automations are rebuilt, not copied

Workflows don’t migrate. Even between platforms that look similar, triggers, enrollment rules, delays and branching work differently enough that a direct copy produces something that runs but misbehaves.

We start from what each automation is supposed to achieve. A lead-assignment workflow in the old system might become a round-robin rule plus a routing workflow in the new one. A tag-triggered welcome sequence might become a list-triggered flow with a profile filter. Some old automations don’t need rebuilding, because they only existed to patch a limitation of the previous platform. We document each one with its trigger, purpose and new equivalent, so nothing important disappears without a decision.

The same applies to integrations. Every connection to the old CRM has to be repointed or rebuilt, and that’s a good moment to fix the ones that were fragile. See CRM integration for how we approach that part.

How a migration runs

Planning the cutover

The cutover is the window between “stop using the old system” and “start using the new one”. It needs a plan, because business doesn’t stop while you migrate. We agree a freeze point, after which no new data is entered in the old system, or we run a delta load that picks up records created or changed after the main import. Forms, integrations and email sending are switched in a set order so nothing is captured twice or not at all. The old system stays available, read-only where possible, until the team is confident nothing is missing.

Most migrations take somewhere between three and ten weeks depending on data volume, the number of objects and integrations, and how much cleanup the data needs. Pricing is quoted after discovery. Related starting prices are on the pricing page.