There is a system in your firm that everyone complains about. There has been a proposal to replace it for at least two years. Every so often a vendor demo re-energises the discussion, and then a busy quarter arrives and it goes quiet again.
Before the next cycle, it is worth separating three things that get bundled together in the complaint.
What people actually mean
"It is hard to use." Sometimes true of the software. More often true of the configuration: a workflow set up during implementation by a committee that no longer exists, enforcing steps nobody can now justify. That configuration follows you to any replacement, because the same committee will specify the new one.
"It does not do X." Worth checking whether it does. Firms routinely run on a fraction of what they license, because the modules that would solve the complaint were in phase two, and phase two never happened. We have seen firms specify a replacement whose headline feature was already installed and unconfigured in the incumbent.
"I have to use three systems to do one thing." This is the real one, and it is usually not solvable by replacing any single system. It is an integration and process question, and a new platform without integration work reproduces it exactly.
The question that shortens the debate
Ask the people who complain loudest to describe the last time the system stopped them doing something a client was paying for.
You will get one of two answers. Either a specific, repeated, costly example, in which case you have a business case and you should build it properly. Or a pause, followed by something general about it being clunky, in which case you have a satisfaction problem and replacing a seven-figure platform is an expensive way to address it.
Both are useful. Only one justifies a programme.
If replacement is right, decide these before the demos
Vendor demonstrations are designed to move you past exactly the questions that determine whether the project succeeds.
Who owns the decision, and who owns adoption afterwards? Not the committee. One name. Implementations fail at adoption far more often than at installation, and adoption needs a person with authority after go-live, not just before contract.
What is the seven-year total? Licence, implementation, data migration, integration, internal time, and the annual uplift in the later years of the agreement. Compare that against the cost of finishing what you have.
How do you leave? Data export in a usable format, termination assistance, and what happens to your information if you go. Negotiate that before signing, because after signing you have no leverage.
What are you turning off? A replacement that adds a system rather than replacing one has made the sprawl problem worse, and this is the commonest outcome in professional services firms.
The middle path most firms skip
Between "live with it" and "replace it" there is a third option that is usually cheapest and almost never proposed by anyone with something to sell: finish the implementation you already bought, fix the configuration to match how the firm works now, integrate the two systems that cause the reconciliation, and train people properly.
That work has a lower ceiling than a replacement. It also has a fraction of the cost and risk, and if it does not resolve the complaint you have learned something specific and you can replace with confidence.