Switching CRMs? Your Definitions Won't Migrate With Your Data

Emily Goh · 2026-11-07

It's week two on the new CRM. The migration went "fine." Every record came across, the field counts match, and the vendor has closed the ticket. Then the first pipeline review opens with two numbers for the same quarter. The old system said $2.4M in qualified pipeline. The new one says $1.9M. Same deals, same people, same data.

Nobody lost $500K. What got lost was the meaning.

Here is the short answer to "what belongs on a CRM migration checklist for definitions?" Before you move a single record, write down what each key number means in the old system: the rule, the field it lives in, the automations and report filters that shape it, and who owns it. Decide which definitions you are keeping, which you are changing, and record the change. Then test the new system against those written rules, not against the old dashboard. Your data will migrate. Your definitions will not, unless you carry them.

Why definitions don't come across in the export

A CSV moves values. It does not move the reasons behind them.

Go back to that $500K gap. Say that in the old CRM, "Qualified" had picked up three years of unwritten habits: a workflow that set it after a demo, a report filter that quietly left out renewals, a manager who moved deals there after one good call. None of that was in the export.

Most of what a metric means lives outside the field itself. It sits in workflow rules that set a stage when something happens. It sits in validation rules that block a save. It sits in report filters someone built years ago and nobody has opened since. And a lot of it sits in people's heads: "we never count a deal as Commit until legal has the paper."

When you rebuild in a new tool, the fields get mapped one to one. Stage to stage, amount to amount, lead status to lead status. The mapping looks complete. But the logic that gave those fields their meaning has to be rebuilt by hand, and anything nobody wrote down gets rebuilt from memory, or not at all.

That's why the first month on a new CRM can feel like the numbers are wrong. Usually they aren't wrong. They're answering a slightly different question than they used to.

The good news: your skills travel

If you've run ops in one CRM, you can run ops in another. Knowing how to design a stage model, set up routing, or spot a broken report is not tied to a logo. The buttons are in different places. The thinking is the same.

What doesn't travel is the agreement. "Closed won" means whatever your company decided it means, and that decision lives in your business, not in the software. If you haven't written it down, the new system can't inherit it. We've covered this in how to define closed won, and it matters even more when you're about to change tools.

So treat the migration as two projects. One is moving the data. The other is moving the definitions. It's easy to plan only for the first.

The definitions half of your migration checklist

Do this before the data moves, while the old system is still there to check against.

1. List the numbers leadership actually uses. Not every field. Start with the ten or so that show up in board decks, forecast calls and comp plans: pipeline, MQL, SQL, Commit, closed won, ARR, churn.
2. For each one, write the rule in one or two plain sentences. For example, say: "A deal counts as Qualified once a discovery call is logged and a budget range is entered. Renewals are excluded."
3. Find where the rule is enforced today. Which field holds it, which workflow sets it, which report filters it. Open the old reports and read the filters. This is where the surprises are.
4. Name an owner for each definition. One person who can say "yes, that's what we mean" when a question comes up.
5. Mark each one keep, change or retire. A migration is a natural time to fix a bad definition. Just make the change on purpose and write down what changed and why, so nobody compares old and new numbers as if they meant the same thing.
6. Turn each rule into a check you can run. "Every Qualified deal has a discovery call logged." "No renewal sits in new business pipeline." If you can't check it, it isn't really a rule yet. Our post on what a data guardrail looks like shows the format.

Test the new CRM against the rules, not the old dashboard

A common migration test is to compare the new dashboard to the old one and chase every gap. That feels sensible, but it treats the old system as the truth. If the old report had a hidden filter, you'll spend a week rebuilding a mistake.

Test against the written rules instead. Take a sample of records and check them one by one. Does every deal marked Qualified meet the Qualified rule? Did the amount field keep the same meaning, or did it switch from first-year value to total contract value? Are dates still dates, or did some arrive as text?

When old and new numbers differ, you now have something better than an argument. You can point at the rule and see which system follows it. That's the whole idea behind business data accountability: knowing what a number rests on and who owns it, so a gap becomes a question with an answer.

What to do this week

If a CRM switch is on your roadmap, even a year out, you can start now.

1. Pick five numbers your leadership team argues about most and write each definition in one or two sentences.
2. Open the report behind each one and write down every filter you find.
3. Put a name next to every definition. If nobody wants to own one, that's useful to know before the migration, not after.
4. Share the list with Sales, Marketing and Finance and ask one question: "Is this what you mean?" Collect the disagreements now.
5. Add "definitions signed off" as a gate in your migration plan, before the data cutover date.

Where Gohvio fits

Gohvio helps with the definitions half. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio then checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only, so it reads your CRM and does not write to it.

That means you can hold your data to the same written rules before and after the move, and see exactly where it falls short.

Stop debating your data. Start making evidence-based decisions.