Before you replace your ERP or CRM: signs the tool isn't the problem

The ERP feels too small, nobody uses the CRM, the reports don't add up, the vendor is slow to respond. At some point somebody says it out loud: "we should replace the system." It's one of the most expensive decisions a small or mid-sized company makes — and not because of the licence: because of the migration, the months of old and new running side by side, the whole team learning again, and the surprises that surface halfway through. Before signing it, one question deserves a slow answer, and it almost never gets one: is the tool really the problem? Because if it isn't, the new system inherits the problem — with an invoice attached.

A new system doesn't bring order — it demands it

A migration carries your data exactly as it is and your people exactly as they work. If every salesperson fills in the CRM their own way today, they'll do the same tomorrow, on prettier screens. If nobody knows at what point a quote becomes an order, the new ERP won't know either.

An ERP or a CRM defines where things are stored and which steps it offers; it doesn't decide how your company works, and it doesn't enforce the discipline of using it well. That gets decided outside the software — and if it hasn't been decided, any system will simply reflect the ambiguity it's fed. This is why so many system replacements disappoint: the tool was expected to bring order, when in fact it was asking for it.

Three signs the tool isn't the problem

The process isn't defined

Try this: ask three people how a quote becomes an order, or when a customer counts as "lost". If you get three answers, your current system isn't failing — it's faithfully executing that ambiguity. Software can't run a process that doesn't exist, and the new system won't be able to either.

The data is dirty

Duplicate customers, free-text fields where there should have been a list, statuses everyone interprets their own way. Migrating dirty data costs you twice: you pay to carry it into the new system, and you poison the first impression. When the team opens the new system and the first thing they see is that "this doesn't add up either", adoption — the most fragile part of the whole project — dies within weeks.

Nobody owns the system

There's no functional owner: nobody decides which fields exist, who gets which permissions, what each status means. Everything was added over the years through one-off requests. Without an owner, the new system will degrade in exactly the same way — only faster, because it starts with a clean slate and everyone has requests saved up.

If you recognise one or more of these signs, replacing the system doesn't solve the problem: it moves it to a new address.

When a switch is actually justified

Honest judgement works in both directions. There are legitimate reasons to replace a system:

• The business no longer fits the system's model. You sell services and the system thinks in warehouses and part numbers; you work by projects and the system only understands orders. When the mismatch is conceptual, not configurable, no amount of tweaking saves it.
• The product has been abandoned. The vendor isn't evolving it, support doesn't respond, every update is a gamble. A system with no future is a risk, not a saving.
• Keeping it alive costs more than replacing it. When daily operations depend on a collection of workarounds, manual exports and satellite spreadsheets compensating for what the system won't do, the cost of the workaround has become structural.
• There's a real, verified technical limit. It can't integrate with anything, there's no reasonable way to get the data out, it doesn't support something the business genuinely needs. Verified means exactly that: checked with your current vendor, not assumed.

Notice that none of these reasons is "the team doesn't use it" or "the numbers don't add up". Those two almost always point back to the signs above.

If you do decide to switch, switch with the work done

Even when the change is justified, the order of the steps matters:

1. Define the process before choosing a system. Choosing means comparing against something; without a defined process, the comparison is won by the best demo.
2. Clean before you migrate. And decide which history deserves to travel: migrating everything just in case means paying to relocate the mess.
3. Name the owner before go-live. The person who decides fields, permissions and criteria has to exist on day one, not appear once things need fixing.
4. Migrate less than you think. Every customisation and every inherited record you leave behind is future maintenance you're spared.

The best moment to put things in order is before the migration, not during it. And sometimes that groundwork delivers an awkward surprise: once the order is in place, the current system has far more to give than it seemed. A prior data and systems assessment exists precisely so you find that out before signing, not after.

Five questions before you sign the switch

1. Can we describe, without "it depends", the process the new system has to run?
2. Is the data we'd migrate clean, or would we be migrating the mess along with it?
3. Who will own the new system — by name?
4. What exactly can the current system not do, and have we verified that with the vendor?
5. If we did the cleaning and ordering the migration demands today, would we still want to switch?

The fifth question is the one that prevents the most replacements. And when the answer is still yes, it's also the one that makes the switch — this time — succeed.