RevOps

How to Avoid Rebuilding Bad Processes in a New CRM

Posted 24 Aug, 2026 by

The biggest waste in a CRM migration is faithfully rebuilding the broken process you were trying to escape. New tool, same dysfunction.

Most CRM migrations replicate the old process in a new system. The stages get copied across. The workflows get rebuilt to match. The same habits carry over. Then everyone wonders why the shiny new CRM feels a lot like the old one within a quarter.

A migration gives you one cheap chance to redesign how you run. Most teams use it to change where they run instead. Waste that and you have paid a lot of money to relocate your problems.

Why teams rebuild the bad process

It is the path of least resistance, for understandable reasons:

  • Copying what exists is faster and feels safer than rethinking it
  • Reps want the new system to work the way the old one did, because change is uncomfortable
  • Under deadline pressure, "just get it live" beats "get it right"
  • Nobody stops to ask whether the old process was actually any good, or just familiar

So the old config becomes the spec for the new build, dysfunction included.

The cost of lift-and-shift CRM migration

When you reverse-engineer the new CRM from the old one, you spend the migration budget recreating the exact stages that never reflected reality, the automations that fought each other, the fields nobody filled and the handovers that always dropped leads. The tool is new. The experience is not. And because everyone is now invested in the migration, the broken process gets a fresh coat of legitimacy.

You have not migrated to something better. You have re-platformed the same problems. Process is one half of a clean migration. Your data is the other. Click here to read our guide: CRM Migration: 8 Steps to Prepare Your Data First.

How to redesign your process instead of replicating it

Separate what you do from how you did it

Map the process you want, the real steps a deal or lead should move through, independent of how the old tool happened to model them. The old configuration is a record of decisions made under old constraints, not a blueprint for the new system.

Question everything before you rebuild it

For each stage, workflow, property and rule you are about to recreate, ask one thing: are we keeping this because it works, or because it is there? Anything that survives only on inertia does not deserve a place in the new build. Fields are where this bites first, because more of them rarely means better answers. Click here to read why the right fields beat more fields.

Design the process first, then configure to match

In HubSpot terms, this means agreeing your deal pipeline stages and entry criteria before you build them, defining lifecycle stages and the properties that move a record between them, and setting required fields per stage so the process holds. Point your workflow enrolment triggers at the agreed model, not the old portal's habits.

Get the operating model right on paper, stages with clear criteria, definitions, ownership, handovers, then build the CRM to fit it. Configuring first and hoping the process emerges is how you ended up here. This is the operating model work, done before you touch a single setting. Click here to read our RevOps framework for B2B SaaS in 2026.

Use the move as a forcing function

A migration gives you permission to reopen questions teams usually avoid. What does qualified mean? Where does ownership pass? Which metrics matter? Settle those fresh rather than importing the old fudges.

Bring reps into the redesign

The way to beat "we have always done it this way" is to involve the people who work the process in improving it, so the new way is genuinely better for them, not just different. Familiarity is a real adoption factor. Earn it by making the redesign obviously easier to work, not by preserving the old mess.

Do not over-correct into fantasy

The opposite failure is designing an idealised process the team will never follow. Redesign for how your people actually sell and operate, not for a textbook. The goal is better and real, not perfect and ignored.

The test

Before you rebuild anything in the new CRM, run it through one question: keeping this because it works, or because it is there? That single filter is the difference between a migration that fixes your operation and one that just changes its address.

The point

A new CRM does not improve your process. Only redesigning the process does. The migration is the moment to do it, while everything is already in motion and open to change. Map how you should work, question everything you are tempted to copy, and build the system to fit the better process, not the old one. Otherwise you have bought a more expensive version of the thing you wanted to leave.

If you are migrating and want to come out with a better operation rather than a re-platformed old one, the redesign is the part we care most about.

A RevOps Audit maps your current setup and shows what to keep, cut or rebuild before anything moves. Our HubSpot Implementation then builds the CRM around the process you want, with adoption and reporting baked in.

Book a call with the team.

 

Get in touch

 

Lewis Chawko is the founder of ROC, a fractional RevOps consultancy helping B2B tech startups and scaleups build revenue systems that scale on HubSpot.

 

FAQs

Most teams rebuild the old setup in the new system. They copy the stages, match the workflows and carry over the same habits. The tool changes, the process does not. Within a quarter the new CRM feels like the old one, because the dysfunction came along for the move. A migration only improves your operation if you redesign the process, not the place it runs.
Start with the process you want, not the one the old tool recorded. Map the real steps a deal or lead should move through, then set clear criteria, definitions and ownership at each stage. Question every property, workflow and rule before you rebuild it, and keep only what earns its place. Configure the CRM to fit the agreed model. Involve the reps who work the process so the new way is easier to run.
No. A CRM stores and runs your process, it does not design it. Migrate a broken process and you get a more expensive version of the same problem. The migration is the moment to fix it, while everything is already moving and open to change. Redesign the operating model first, then build the system around it.