CRM Migration Guide: How to Switch Platforms Without Losing Data

A CRM migration succeeds or fails on three things: how clean the data is before it moves, whether automations and integrations are rebuilt (not just copied), and whether there’s a real validation step before the old system gets turned off. Skipping any of the three is the most common reason migrations run over budget or over schedule.

Signs it’s actually time to switch

A migration is worth planning when one or more of a handful of specific signals shows up, not just a general sense that the current system feels dated. Before planning a migration, it’s worth being honest about why. The clearest signals: your sales process has outgrown what the current platform can configure (custom objects, approval chains, multi-product pipelines); you’re paying for features across two or three disconnected tools that a single platform could replace; your current CRM was implemented badly and a data-model rebuild would cost nearly as much as a migration; or your team has stopped trusting the reports because the underlying data is unreliable. If none of these apply, the better fix is usually a remediation project on the current platform rather than a full migration — switching platforms doesn’t fix bad data discipline, it just moves it. If you haven’t settled on a destination platform yet, the CRM buyer’s guide covers how to match a platform to your team size and process before you start planning the move itself.

A useful test before committing to a full migration: would fixing the data model and rebuilding automation on the current platform solve 80% of the pain at a fraction of the cost and risk? If the honest answer is yes, remediation is the better first move — you can always migrate later, but a migration doesn’t undo itself once the old system is decommissioned. Migration makes the most sense when the platform itself, not just its configuration, is the actual constraint.

What migration actually costs, by platform

Data migration isn’t a fixed-price line item — it’s a percentage of a broader implementation budget, and that percentage varies meaningfully by destination platform. The chart below shows data migration’s typical share of total implementation cost across seven platforms, drawn from the phase breakdowns in aibrevo’s implementation cost guides:

The pattern is worth understanding before you budget: Pipedrive is deliberately the simplest platform on this list, so there’s little customization work to absorb budget — migration complexity (deal and contact volume, de-duplication) becomes the dominant cost driver almost by elimination, at roughly 35% of the total project. HubSpot and Zoho sit in the middle at 20%, reflecting a meaningful data-mapping effort (lifecycle stages on HubSpot, suite-wide field mapping on Zoho) without the deep custom-code work Salesforce or Dynamics 365 projects absorb. Salesforce, Dynamics 365, Airtable and monday.com all cluster around 15% — not because migration is easier on those platforms, but because a larger share of their budgets goes to configuration, automation rebuild and integration work instead. The takeaway for planning purposes: don’t assume a “simpler” platform means a cheaper migration — it often just means migration is a bigger fraction of a smaller number.

Step 1: Audit your current data before touching anything

Export a full snapshot of your current CRM and look at it honestly: how many duplicate contacts and companies exist, how many required fields are actually populated, how consistent are picklist values (three ways of spelling “Enterprise” is common), and how many records are genuinely stale versus active. This audit determines your real migration scope — a database that looks like 50,000 contacts often has 30,000 usable ones once duplicates and dead records are identified.

Run this as a structured exercise, not a quick skim: pull a random sample of 200-500 records and manually check field completeness, then extrapolate the pattern to the full database. Look specifically for fields your reports depend on — if 40% of deals are missing a close-date or 60% of contacts have no associated company, that’s not a migration problem to solve later, it’s a data-quality problem the migration will otherwise carry forward unchanged. The audit result should be a written scope, not an impression: X records total, Y estimated duplicates, Z fields below an acceptable completeness threshold.

Skipping this step is expensive, and it’s expensive in a way multiple independent research efforts now put a number on. Enterprise data-migration research compiled by Kanerika’s 2026 migration report cites failure-or-overrun rates on data migration projects in the 70-85% range depending on how “failure” is defined — missed budget, missed timeline, or unmet business objectives — and consistently identifies underestimated source-data complexity, discovered too late, as the leading cause rather than tooling or destination-platform choice. A separate, widely-cited Bloor Research analysis of enterprise data migration projects found that poor source-data quality was responsible for roughly 53% of migration cost and schedule overruns specifically. Put a number on that for your own project: a 50,000-contact migration budgeted at $15,000 that overruns by even a conservative 30% — a below-average outcome given how often these projects run over — costs an extra $4,500 that a week of audit work up front would have mostly prevented. The audit isn’t a formality before the “real” work starts; skipping it is how a fixed-scope migration quietly turns into a time-and-materials one.

Step 2: Map fields between systems

Every CRM structures data slightly differently — deal stages, lifecycle stages, custom fields and required-field rules rarely line up one-to-one. Build an explicit field-mapping document before any data moves: which source field maps to which destination field, what happens to fields with no equivalent (drop, combine, or create a new custom field), and which picklist values need to be normalized during the move. This is the step most DIY migrations skip, and it’s the one that causes the most post-migration cleanup.

A field-mapping document that actually works has a row per source field with four columns: destination field, transformation needed (none, format change, value normalization, or combine-with-another-field), owner of the decision, and a status (mapped, pending, or intentionally dropped). Review it with someone from sales, not just whoever is running the technical migration — a field that looks safely droppable to an admin (“Secondary Phone,” say) might be load-bearing for how a specific team actually works, and that’s much cheaper to catch on a spreadsheet than after go-live.

Field-mapping mechanics differ enough by platform that a generic checklist misses real failure points. HubSpot’s own import documentation requires at least an email address for a contact record to import at all, and dropdown-style properties have to match an existing option’s spelling exactly — importing “open” against a property that only has “Open” as a defined value fails that row silently rather than throwing a visible error, which is why a mapping review needs to check picklist values, not just field names. HubSpot also caps free-tier imports at 500,000 rows and 20MB per file in a rolling 24-hour period, rising to 10 million rows per day and 512MB per file on paid tiers, according to HubSpot’s own import documentation — numbers worth checking against your actual record count before assuming one file will do the job. Salesforce migrations typically split into three tool tiers depending on volume and complexity: the built-in Import Wizard for small, simple loads, Data Loader for bulk operations, and a full ETL or iPaaS tool when multiple source systems and real transformations are involved — using Data Loader for a job that needs proper ETL is a common way small migrations quietly turn into unreliable ones. Pipedrive’s import flow surfaces detected duplicates at the preview stage, based on matching fields like email and phone, and routes anything that fails to import — missing mandatory fields, malformed values — into a downloadable “skip file” for correction and re-import rather than failing the whole batch, per Pipedrive’s own support documentation. GoHighLevel’s import only accepts CSV (Excel and Google Sheets files need exporting to CSV first) and requires each row to carry an email or phone number so the system has something to match against, per HighLevel’s support documentation — a blank identifier column is the single most common reason a GoHighLevel import batch fails partway through.

Step 3: De-duplicate before you migrate, not after

De-duplication is dramatically easier in the source system, where you likely already know the data, than after 30,000 records land in an unfamiliar new platform. Run a merge pass on obvious duplicates (same email or domain, near-identical company names) before export. Anything migrated as a duplicate becomes two records to manage forever in the new system. aibrevo’s dedicated guide on cleaning CRM data before migration goes deeper on the mechanics than fits here if de-duplication is the bulk of your project’s risk.

Work through duplicates in tiers of confidence rather than trying to resolve every case with one rule: exact email matches can usually be auto-merged safely; near-identical company names or matching phone numbers with different spellings need a human eyeball pass before merging, since an aggressive automated merge can just as easily combine two genuinely different companies as it catches a real duplicate. Whatever tool or script does the merging, keep a log of what was merged into what — if a merge turns out to be wrong, you need to be able to trace it back and split the record apart.

The scale of this problem is bigger than most teams assume going in. Industry data on legacy CRM databases consistently finds that 30-50% of existing records are duplicates, outdated, or incomplete before any cleanup work starts, and even a database a team believes is reasonably clean typically turns up a 10-30% duplicate rate once a proper de-duplication pass actually runs against it. That gap between assumed and actual data quality is exactly why the structured audit in Step 1 matters more than a quick look — “our data’s mostly fine” and “we checked and it’s 22% duplicates” lead to very different migration plans.

Step 4: Rebuild automations and integrations — don’t just export them

Workflows, lead-routing rules, and third-party integrations rarely transfer directly between platforms; they need to be rebuilt against the new platform’s logic and field structure. This is usually the most underestimated part of a migration budget. Before cutover, list every automation and integration the current CRM runs and confirm each has an equivalent built and tested in the new system — a “just migrate the data” plan that ignores this list is the most common cause of a rocky first month after go-live.

Build the list as an inventory with three columns: what the automation does, how often it fires, and what breaks if it doesn’t exist on day one. That third column is what usually gets skipped, and it’s the one that determines sequencing — an automation that silently stops a weekly report from generating is lower priority to rebuild before cutover than one that stops leads from being routed to a rep at all. Not every automation needs to exist on go-live day; some can be rebuilt in the first two weeks post-launch if the gap is tolerable and clearly communicated.

This is also where export limitations catch teams by surprise, particularly on platforms built around automation rather than raw data storage. GoHighLevel’s own support documentation is explicit that a contacts CSV export doesn’t contain automation event history, conversation context, integration configuration, or workflow state — an export gets you the contact record, not a recreation of the account, and each sub-account has to be exported separately. That’s not a GoHighLevel-specific problem so much as a general rule worth internalizing: any platform’s data export is a snapshot of records, not a portable copy of its automation logic, which is exactly why “rebuild, don’t copy” has to be the working assumption for this step regardless of source or destination platform.

Step 5: Test in a sandbox before the real migration

Run a full migration into a sandbox or staging environment first, using real (anonymized if needed) data, and have the actual end users — not just admins — check that their records, pipelines and reports look right. Problems caught in a sandbox cost an afternoon to fix; the same problems found after go-live cost a week of user trust. Test at realistic data volume specifically — a migration that looks clean with a few hundred sample records can behave very differently once 30,000 or 50,000 real records, and whatever automation fires on them, actually run through the system.

For Salesforce migrations specifically, this step has a name in most migration playbooks: an end-to-end rehearsal, run in a full sandbox with production-scale data, load order respected (parent objects loaded before child records, external IDs defined ahead of time so re-runs don’t create duplicates), and record counts reconciled against the source afterward. Treat the rehearsal as a real dry run of cutover day, not just a data-integrity check — if a step in the rehearsal takes four hours, it’ll take roughly four hours on the actual day too, which is exactly the information a freeze-window plan needs.

Step 6: Plan the cutover window and freeze period

Pick a specific cutover date, not “sometime this month.” In the days before cutover, freeze significant changes to the old system (or run a delta sync) so the final migration captures everything created in the interim. Communicate the freeze window to the team clearly — most migration complaints come from records created or changed during an undocumented freeze window.

A parallel-run period ahead of the actual freeze reduces the pressure on cutover day considerably. Keep the old system as the system of record while the new one runs in a read-only or delayed-sync mode for a week or two, and have reps spot-check that what they see in the new system matches what they’d expect from the old one. This turns cutover from “the day we find out if it worked” into “the day we flip a switch we’ve already tested,” which is a meaningfully different risk profile, especially for teams that can’t tolerate an unplanned outage during business hours.

Step 7: Write the rollback plan before you need it, not during an incident

A rollback plan is not the same document as a migration plan, and most teams that skip it don’t realize they’ve skipped it until something goes wrong mid-cutover. A real rollback plan names a specific trigger condition in advance — not “if something breaks,” but a concrete threshold like “if more than 5% of migrated deals fail validation” or “if the new system’s automations haven’t fired correctly on the first 50 live records” — because deciding what counts as bad enough to reverse is a much worse decision to make in the middle of an incident than ahead of one.

The mechanical requirements are straightforward but easy to shortcut under deadline pressure: keep a full, untouched backup of the source system taken immediately before cutover, know exactly how long that source system stays accessible and in what state (read-only is standard), and assign one named person the authority to actually call a rollback rather than leaving it to group consensus during a live incident. Migration guidance from Salesforce implementation specialists consistently frames this the same way — document the rollback path, back up both source and target, and actually test a restore beforehand so recovery is a rehearsed procedure rather than an improvisation. Keep the old system available in a read-only state for a defined period after a successful cutover too — often 30 to 90 days — rather than deleting it immediately; it’s the only reference point for tracing a discrepancy back to its source if one surfaces weeks later, and it doubles as the rollback target if an issue is serious enough to warrant reversing the migration entirely.

What a realistic timeline looks like by data volume and complexity

Migration timelines scale with three variables more than any other factor: record count, number of custom fields and automations to rebuild, and integration count — and they don’t scale linearly. A small, clean migration compresses almost every step in this guide into days; a large, messy one with heavy automation and many integrations stretches the sandbox-testing and automation-rebuild phases out disproportionately, because those are the phases where complexity compounds rather than just accumulates.

The step that expands most under volume and complexity isn’t the data transfer itself — moving 100,000 records instead of 5,000 is mostly a matter of runtime, not risk — it’s sandbox testing and automation rebuild, because more custom fields and more automations mean more edge cases a rehearsal has to actually surface before cutover. A migration that budgets its timeline purely off record count, without weighting for automation and integration complexity, is the most common way a “should take a month” migration turns into a three-month one partway through.

Handling a multi-system consolidation, not just a single swap

Not every migration is a clean one-CRM-to-another move. A common, harder variant: consolidating a sales-only CRM, a separate marketing tool, and a spreadsheet a regional team keeps into one destination platform. The extra complexity isn’t technical so much as it’s about conflict resolution — when the same contact exists in two source systems with different phone numbers or lifecycle stages, someone has to decide which value wins, and “most recently updated” isn’t always the right rule if one system is updated far more often than the other regardless of accuracy. Match records across sources on the most reliable shared identifier available (usually email domain plus normalized company name, since a single unique ID rarely exists across three independent tools), and resolve conflicts before the consolidated import, not with a post-import dedup pass — most platforms’ built-in duplicate tools are built to catch a new duplicate created by a single user, not to reconcile a three-way merge with conflicting field values.

Sequencing sales data ahead of marketing data

For teams migrating both a sales pipeline and marketing data (lists, campaign history, consent records) into the same destination platform, migrating in two phases rather than one reduces risk meaningfully. Validate the sales pipeline first — deals, contacts, and the automations reps depend on daily — since a broken pipeline is immediately visible and costly. Layer marketing data in as a second phase once sales is stable, particularly consent and subscription status, which usually needs its own explicit mapping rather than inheriting a default from the contact record. Rushing both phases into a single cutover multiplies the number of things that can go wrong on the same day, for a time savings that’s rarely worth the added risk on a migration of any real size.

Step 8: Validate after go-live, not just before

After cutover, run a structured validation pass: spot-check a sample of migrated records against the source system, confirm automations fire correctly on real new records, and check that integrations (billing, support, marketing) are receiving and sending data correctly. Budget at least a week of close monitoring after go-live before considering the migration complete.

A useful validation checklist covers four categories rather than one general “does it look right” pass: record-count reconciliation (does the new system’s total match the audited source count, accounting for intentionally-dropped stale records); field-level spot checks against a sample large enough to be meaningful, not five records picked at random; live automation tests run against real new records rather than trusting that a sandbox pass generalizes; and integration checks confirming that billing, support, and marketing tools are both receiving from and sending to the new CRM correctly. Skipping the integration check specifically is a common blind spot — a CRM can look perfectly migrated from inside its own UI while a connected billing tool is silently failing to sync because a webhook still points at the old system’s API endpoint.

Common failure modes, and what each one actually costs

Most migration problems trace back to a small, repeatable set of root causes rather than genuinely novel failures, which is exactly why they’re worth naming explicitly rather than treating each incident as a one-off surprise.

Migrating dirty data as-is, without the Step 1 audit, is the most common and most expensive failure mode — it doesn’t just carry duplicates forward, it also carries forward the false confidence that comes from “the migration technically succeeded” while reports quietly become less trustworthy than before. Underestimating automation rebuild is the second most common one, and it’s the failure mode most likely to be discovered by a customer rather than internally, since a broken lead-routing rule often shows up as a lead nobody called back rather than as an error message anywhere. Skipping the sandbox rehearsal is the failure mode most correlated with cutover-day chaos specifically, because problems that would have surfaced in a controlled test instead surface in front of the whole team on go-live day. And treating field mapping as a mechanical, admin-only task rather than a business-logic review is the failure mode most likely to produce quiet, long-tail damage — a dropped field or a mismapped picklist value that nobody notices for months, until a report or a compliance question depends on data that simply isn’t there anymore.

The cost of each failure mode compounds the longer it goes undetected. A duplicate record caught during the Step 1 audit costs a merge click. The same duplicate caught six months after go-live, once it has its own history of notes, deals, and automation triggers attached to it, costs a careful manual reconciliation to avoid losing legitimate activity in the merge. That asymmetry — cheap to fix early, expensive to fix late — is the single strongest argument for front-loading the audit, mapping, and de-duplication steps rather than treating them as boxes to check quickly on the way to the “real” migration work.

Platform-specific migration guides

If you already know your destination platform, the general steps above still apply, but the specifics differ meaningfully by platform. See the dedicated guides for migrating to Salesforce and migrating to HubSpot, or the implementation pages for Zoho CRM, Pipedrive, Microsoft Dynamics 365, monday.com CRM, Airtable and GoHighLevel. If you’re still deciding on a destination, the HubSpot vs Salesforce and Zoho vs Salesforce comparisons both include a “migration” section covering what switching between those two specific platforms typically involves. For teams migrating specifically onto GoHighLevel from a sales-focused CRM, HighLevel Automation Team specializes in the automation-rebuild side of that particular move, which is usually the harder half once the raw contact data itself is safely imported. Once your migration checklist is scoped, the CRM implementation checklist covers the broader project plan a migration sits inside, from kickoff through user adoption.

Get a migration scoped properly

Migration cost varies more with data quality and integration count than with the destination platform’s list price. A free 30-minute call gets you an honest read on your current data and a real estimate of what your specific migration involves — not a generic quote.