MELLORCATalk to Mellorca
Insights

CRM and Customer Systems

When to Reconfigure a CRM and When to Replace It

Most CRM frustration is a setup or adoption problem, not a product problem. Here is how to tell which, and when replacement is genuinely justified.

Mellorca Insights2026-11-01

A sales manager in Bryanston tells the owner that the CRM is "useless" and that the team should switch to something newer. Two questions later, it emerges that half of the stages in the pipeline were copied from a template nobody checked, three people use the notes field for different things, and the quote workflow lives in a spreadsheet beside the system. The software may be fine. Or it may genuinely be wrong for the business. The cost of guessing wrong is high either way: a needless replacement burns months and trust, while a stubborn defence of the wrong tool keeps the team working around it for years.

This article offers a way to tell the two situations apart before anyone signs a new contract.

Start with what the complaint is actually about

Frustration with a CRM usually arrives as a verdict on the product. The useful move is to turn it into a list of specific, observable failures. "The CRM is slow" might mean the screen takes eight seconds to load, or it might mean that finding the right customer takes five clicks because the account structure is a mess. "We can't trust the data" might point to duplicate records, to fields that nobody is required to fill in, or to a sync that quietly fails each night.

Write each complaint on a line and add three columns: who experiences it, how often, and what it costs when it happens. A missed follow-up that loses a quote is a different order of problem from an awkward report layout. Once the list exists, most items fall into one of three buckets.

  • Configuration problems: the system can do the thing, but it is set up in a way that does not match how the team works. Stages, required fields, page layouts, permissions and assignment rules sit here.
  • Adoption and process problems: the system is set up reasonably, but the work around it is undefined, so people enter data inconsistently or not at all. Our piece on why CRM adoption problems are often workflow problems covers this bucket in depth.
  • Capability problems: the product cannot do something the business genuinely needs, or can only do it at a cost or fragility that the business cannot accept.

Replacement is only the right answer for the third bucket, and often not even then. In our experience the first two buckets account for most of the complaints that reach an owner's desk.

Test the configuration before you blame the product

A system that has been reconfigured badly will feel like a system that needs replacing. Before deciding, check whether the basics reflect the real sales or service process. Do the pipeline stages describe what the team does, or what a vendor's sample data suggested? Our article on designing CRM stages that match what your team actually does explains how to test this. Do the required fields capture information someone later uses? Are there fields nobody has touched in a year that clutter every screen?

It also helps to read what the vendor ships as standard. Microsoft's Dynamics 365 Sales documentation is one example of how a vendor describes the out-of-the-box record types and capabilities of a CRM, and the same exercise works with any product you already own. Teams are often surprised to find that a feature they wanted already exists in their current licence, switched off. Ask your vendor or implementation partner for a short list of the features included in your current plan that you are not using.

If a competent person can reconfigure the system in a few weeks and the main complaints disappear, you have your answer. Keep the tool, change the setup, and use the saved budget on training and ownership.

Signs that replacement is genuinely justified

Some situations do call for a new system. The pattern to look for is a problem that persists after the configuration has been put right, or a problem that no configuration can reach. These are the signals we treat as serious:

  • A hard capability gap. The business needs something structural, such as multi-entity invoicing, a quoting model with complex pricing rules, or a portal for customers, and the product either lacks it or offers it only through workarounds the team cannot maintain.
  • Integration limits. The CRM cannot exchange data reliably with the accounting, stock or support systems the business depends on, and there is no supported way to fix that. If the sync is the weak point, read our guide to six checks before you rebuild a broken integration first, since the fault is often in the connection rather than in the CRM itself.
  • Vendor or support risk. The product is being retired, support is unavailable in your time zone, or the vendor's pricing has moved out of reach for your team size.
  • Data residency or compliance constraints. If you handle personal information, the Protection of Personal Information Act places duties on how it is processed and secured. The Act is published on the South African government website. A system that cannot support access controls, retention decisions or deletion requests in the way you need is a legitimate reason to move.
  • Accumulated structural damage. Years of ad hoc customisation have produced a system so tangled that each change breaks something else, and nobody who built it is still around.

The middle path: replace in pieces

The choice is not always between a full rebuild and leaving everything alone. Where part of the system is the problem, it can be replaced while the rest stays in place. Microsoft's description of the strangler fig pattern sets out the principle of incrementally migrating a legacy system by gradually replacing specific pieces of functionality with new ones, so that the old and new run side by side until the old can be retired.

In practice that might mean moving only the quoting step to a better tool while contacts and pipeline stay where they are, or adopting a new support desk and linking it to the existing customer records. It limits the risk, keeps people productive and lets you test whether the new component solves the problem before you commit everything to it.

Count the real cost of switching

Replacement is almost always more expensive than the licence comparison suggests. The costs that surprise businesses are mostly not in the quote:

  • Cleaning and mapping existing data. Migrating duplicates and half-complete records simply moves the mess. Our article on a safe sequence for cleaning up a CRM while the team keeps working is a sensible precursor to any migration.
  • Rebuilding integrations, reports, email templates and automations that currently depend on the old system.
  • The period when two systems hold partial truths and people are unsure which to trust.

If the new system will be configured by the same people, with the same unclear process, the same complaints tend to reappear within a year. The reason is that the cause was never the software. Replacing a CRM without fixing the workflow beneath it is a way of paying for the same lesson twice.

A decision rule you can defend

Put the matter to a simple test. First, would a reconfiguration, led by a named owner and completed within roughly a quarter, resolve the high-cost complaints? If yes, reconfigure. Second, if not, is the remaining gap a capability, integration, compliance or vendor problem that you can describe in a sentence and verify in the product documentation? If yes, replacement or partial replacement is justified. Third, if you cannot describe the gap clearly, you are not ready to choose a replacement, and the next step is more diagnosis rather than a vendor demonstration.

Whichever way you land, write down the reasoning. When the decision is revisited in two years, a clear record of what was wrong and why you chose as you did is worth more than any feature comparison.

Practical next actions

  1. List every CRM complaint from the last quarter, with who raised it, how often it happens and what it costs, and sort each into configuration, adoption or capability.
  2. Ask your vendor or partner for the features included in your current plan that your team is not using, and test the two that address your most expensive complaints.
  3. Name one owner for the CRM who can approve changes to stages, fields and permissions, and give that person a quarter to fix the configuration issues.
  4. For any capability gap that remains, write one sentence describing it and confirm in the product documentation that the gap is real before you look at alternatives.
  5. If you still need a new tool, price the full switch: data cleaning, integrations, reports, training and a parallel-running period, and consider replacing one function first.

Sources and further reading

Related Mellorca reading

Article summaryMost CRM frustration is a setup or adoption problem, not a product problem. Here is how to tell which, and when replacement is genuinely justified.
Explore our solutionsStart a conversation