The new CRM goes live on a Monday. Every record loaded, the row counts match, and the project team signs off. On Tuesday the sales leader opens the pipeline dashboard and sees a third fewer open opportunities than last week. By Thursday finance has found that commissions no longer reconcile. Nobody lost any data. The numbers simply stopped meaning what they used to.

This is how most CRM migrations go wrong. The records move; the reports break. And because executives see the business through those reports, a migration that breaks them feels like a failed project, however clean the data load was.

Why reports break when the data moves

A report depends on far more than the fields it displays. It depends on definitions (what counts as a qualified lead or a committed deal), on history (when a deal entered each stage, who owned it at the time), on record relationships, and on the automations that stamp dates and statuses along the way. Migration tools move records. They do not move meaning.

The data underneath is often weaker than teams assume. In Salesforce’s data and analytics trends research for 2026, data and analytics leaders estimated that over a quarter (26%) of their organization’s data is untrustworthy. Validity’s State of CRM Data Management in 2026 found that 62% of organizations report losing revenue directly due to poor CRM data quality, and nearly a third of teams spend six or more hours a week fixing and reconciling data. A migration exposes every one of those problems at once.

Start with the reports, not the records

Before anyone maps a field, list the reports and dashboards the business actually runs on. In most companies that is a short list: the executive pipeline view, the forecast, commission and quota reports, marketing attribution, and service-level reports for support.

For each one, record:

• The owner and the decision it supports.
• The question it answers, in plain language.
• The fields, filters and rules behind it, including calculated fields.
• A baseline: last month’s numbers, exported and saved.

This list becomes the acceptance test for the whole migration. The project is not done when the data is loaded; it is done when these reports produce the same answers in the new system, or when every difference is explained and agreed.

Agree on definitions before you map fields

Field mapping looks like a technical task, but most of it is a business decision. If the old system has seven opportunity stages and the new one has five, someone has to decide where each old stage lands, and that choice changes the forecast. The same is true for lead statuses, deal probabilities, account types and territories.

Write these decisions down in a short definitions document, and have the report owners sign off on it. Disagreements between sales, marketing and finance will surface here, which is far cheaper than discovering them in the first board meeting after go-live.

Decide what history comes with you

Not every record deserves a place in the new system. A common pattern is to migrate open records and a fixed window of closed business (for example, three years of won and lost deals), then archive the rest in a store that can still be queried.

Whatever you move, keep the dates that reports depend on. Created dates, close dates and stage-change history drive conversion rates and sales-cycle reports. On some platforms this needs preparation: Salesforce, for example, only keeps original created dates on imported records when audit-field import is enabled before the load. Without it, every record looks brand new.

A migration is also a chance to stop carrying data you should not keep. Canada’s privacy commissioner advises organizations to have guidelines for retaining and destroying personal information, and to dispose of it once it has served its purpose. Old contacts with no activity and no legal reason to keep them are a good place to start.

Keep a crosswalk of old and new IDs

Store the legacy record ID on every migrated record, and keep a mapping table of old and new IDs. It costs almost nothing and pays off repeatedly: you can re-run a failed load without creating duplicates, trace any number in a new report back to its source, and join new CRM data to historical data in your warehouse.

Reconcile numbers, not row counts

Run at least one full rehearsal into a sandbox. Then run the baseline reports in both systems and compare totals by stage, owner, region and month. Row counts can match perfectly while the pipeline total is off by millions because one stage was mapped to the wrong place.

Set tolerances in advance. Closed-won revenue and commissions should match exactly; activity counts may tolerate small, explained differences. Script the comparison so it can be re-run after every rehearsal, not checked by hand once.

Plan the cut-over around a reporting cycle

The cut-over itself needs a short freeze on changes in the old system, a final delta load, and a clear order for switching integrations and automations back on. Automations left running during the load can overwrite dates, reassign owners or send emails to customers about records that only moved.

Where possible, run the critical reports in both systems through one full reporting cycle, such as a month-end close. Keep the old system read-only for that period so any question can be answered from the source.

Protect the numbers after go-live

The work does not end at cut-over. Validation rules, required fields and named owners for each definition keep the data from drifting back to where it started. A light data governance plan helps here, and it matters more each year: the AI features now built into CRMs are only as reliable as the records they read.

Plan the move with 247 Labs

247 Labs helps technology and revenue teams plan and run CRM migrations: report inventories, mapping and definitions, reconciliation scripts, and the custom integrations that connect a new CRM to the rest of the business. If a move is on your roadmap, talk to our team about protecting the numbers your business runs on.