CRM Migration: What Breaks When You Switch, and What Doesn't Transfer
Custom fields, dashboards and integrations rarely survive a CRM migration intact. What actually breaks, what to freeze first, and why cutover Fridays fail.
, 4 min read, Sales tech
Key takeaways
- Core records usually migrate fine. What breaks is custom fields that don't map cleanly, workflow automations that must be rebuilt from scratch, and every connected integration that needs to be individually reconfigured.
- The most underestimated cost is rebuilding dashboards and reports, since saved reports almost never migrate, not the core record migration most teams worry about most.
- A short parallel-run period, with old and new systems live at the same time, catches gaps a big-bang Friday cutover only reveals after everyone has already moved on.
Why the record migration is the part teams worry about least accurately
Ask a sales leader what scares them about a CRM migration and most say some version of "losing customer data." In practice, core object migration, accounts, contacts, deals, is the part vendors and migration tools have gotten genuinely good at. What actually breaks, and what teams consistently underestimate, sits one layer below the records: the structure, automation, and reporting built around them.
What doesn't map cleanly: fields, objects, and automations
Custom fields rarely translate one-to-one. A dropdown field with fifteen years of accumulated values, half of them no longer used, either has to be manually remapped to the new system's equivalent or gets dumped into a generic text field that loses its structure entirely. Custom objects built for a specific workflow, a renewal tracker, a partner referral object, often have no direct equivalent and need to be rebuilt from the schema up.
Workflow automations and triggers are worse. These are almost never importable as-is, because every CRM builds its automation logic differently under the hood. A rule that assigns leads based on territory, or a trigger that fires a task when a deal stage changes, has to be recreated by hand in the new platform's automation builder, tested, and validated against edge cases the old system had quietly been handling for years.
Historical activity: it transfers, but not the way people expect
Notes, call logs, and email history generally do migrate, but usually as flat data rather than the original interactive timeline. A note that referenced a custom field since renamed, or was written by a user who has since left the company, can lose the context that made it useful. Timestamps are a recurring headache: time zone handling differs between systems, and activity that looked correctly ordered in the old CRM can appear shifted by hours in the new one if the migration tool doesn't handle the conversion carefully.
The cost most teams don't budget for: dashboards, reports, and integrations
| What people worry about | What actually costs the most time |
|---|---|
| Losing account and contact records | Rebuilding every saved report and dashboard from scratch |
| Historical notes disappearing | Reconnecting and reconfiguring every integration individually |
| Data accuracy after migration | Recreating workflow automations and validating edge cases |
Saved reports and dashboards almost never migrate as functioning objects. Even when a migration tool claims report support, the underlying filters, groupings, and calculated fields frequently need rebuilding by hand to actually match what leadership was looking at before. A forecast dashboard a VP checks every Monday morning can take longer to rebuild correctly than the entire contact migration.
Integrations are the other underrated cost. A sales engagement platform, a dialer, an e-signature tool, a marketing automation platform, each one has its own connector to the CRM, and none of them migrate automatically just because the CRM data did. Each has to be individually reconnected, re-authenticated, and often reconfigured to match new field names or object structures. Teams that plan for "the migration" as a single event routinely discover it's actually a dozen smaller migrations happening in parallel.
What to audit and freeze before migration day
Before any data moves, audit and document three things: every custom field and its current use (cut the ones nobody can explain), every active automation and the specific business rule it enforces, and a full list of connected integrations with who owns each one. Freeze non-essential changes to the old system a week or two before cutover, since a field added or a workflow changed mid-migration is a common source of records that quietly fail to map.
Permission and role structures deserve their own pass. Access rules rarely translate cleanly, and getting them wrong in the new system either locks reps out of records they need or, worse, opens up data that should have stayed restricted.
Why a short parallel run beats a big-bang Friday cutover
The instinct to migrate everything over a weekend and have the new system fully live Monday morning is understandable, and it's usually a mistake. A big-bang cutover compresses the discovery of every gap, a missing field mapping, a broken automation, an unreconnected integration, into a single weekend with no fallback, and whatever surfaces Monday hits a team that has already lost access to the old system.
Running both systems live in parallel for a short window, even just a few days, gives the team a chance to compare records side by side, catch mapping errors while the old data is still queryable, and let reps flag anything that looks wrong before the old system goes dark. It costs a bit more coordination up front and saves a much worse week of firefighting after.
The position worth taking
The core record migration is the part of a CRM switch that gets the most anxiety and deserves the least of it; most tools handle it competently. The real cost sits in rebuilding dashboards and reports that never migrate as functioning objects, and reconnecting every integration individually. Budget time and ownership for those two specifically, not just for "moving the data," and the migration will go noticeably smoother than the horror stories suggest.
Frequently asked questions
- What's most likely to break during a CRM migration?
- Custom fields and objects that don't map one-to-one to the new schema, workflow automations and triggers that have to be rebuilt rather than imported, and every third-party integration, sales engagement tool, dialer, e-signature platform, that needs to be individually reconnected and often reconfigured.
- Do historical notes and activity timelines transfer cleanly?
- They usually transfer as flat data rather than the original interactive timeline. Timestamps can behave oddly depending on time zone handling in the new system, and notes tied to since-deleted fields or users can lose context that made them meaningful.
- Is a big-bang cutover on a Friday a good idea?
- Generally not. It compresses discovery of every migration gap into one weekend with no fallback, and issues that surface Monday morning hit a team that has already lost access to the old system. A short parallel run, even a few days, catches most of those gaps while both systems are still live.