If you are not sure whether your enterprise system needs replacing, an RFP will not tell you. It will tell you what six software companies would like to sell you. Those are different questions, and only one of them costs a year of your staff’s attention to answer.
We see the same sequence often enough that it is worth naming. Finance is frustrated. Reporting takes too long. Someone says the words “the system can’t do it.” A procurement gets scoped, an RFP goes out, and eighteen months later the agency signs a contract for a platform that does roughly what the old one could have done if anyone had reconfigured it.
The problem is not that replacement is wrong. Sometimes it is exactly right. The problem is using the procurement itself as the instrument of discovery.
Why the sequence gets inverted
Going to market feels like progress. It has a calendar, a budget line, and a board resolution. Diagnostics feel like delay.
There is also a supply-side reason. Almost everyone an agency can call for help with this question earns more if the answer is “replace.” Implementation firms bill the implementation. Resellers earn the license. Even well-meaning advisors who also deliver systems have a thumb on the scale they cannot fully remove.
So the optimize answer rarely gets a fair hearing, not because it is wrong but because nobody in the room is paid to argue it.
The three questions that settle it
Before a single requirement gets written into an RFP, an agency can usually resolve replace-or-optimize with three questions asked honestly.
1. Is this a configuration problem or a platform limitation?
Most “the system can’t do that” complaints are really “the system was never set up to do that.” Chart of accounts structures that were copied from the prior system. Approval workflows that were never mapped. Modules that were licensed and never turned on. These are real problems with real operational cost, and none of them are solved by buying a different system — they follow you into the new one.
The test is specific: for each top complaint, can you name the technical constraint in the platform that makes it impossible? If the answer is a shrug or a vendor’s sales sheet, it is a configuration problem.
2. What do you actually need, as distinct from what you currently have?
Requirements documents in the public sector have a habit of describing the incumbent system. That guarantees you buy the same thing again, at a premium.
A requirements traceability matrix built from the work — not the software — can be tested against both futures. Can the current platform, tuned, meet these? Can a replacement meet them meaningfully better? The same document answers both questions, which is what makes the exercise cheap. Do it once, use it either way.
3. What is the honest cost of each path, including the one you are not excited about?
Replacement costs are routinely understated at the decision point, because the number that gets quoted is the license and the implementation, not the staff time, the parallel running, the data conversion, the retraining, or the two years of reduced throughput while an organization relearns its own processes.
Optimization costs are understated too, in the other direction — agencies assume tuning is free because no contract is involved. It is not free. It is just usually an order of magnitude smaller.
Put both on the same page with the same assumptions. The decision often makes itself.
What this looks like in practice
GoTriangle, the regional transit authority for the Research Triangle, engaged us in December 2025 with exactly this question. Rather than open a procurement, the authority commissioned the assessment first: a needs assessment across the functions that depend on the platform, a requirements matrix written from those functions, and a strategic optimization plan that prices both paths — tuning what they own, or going to market — with a roadmap for each.
Whichever way that lands, the work is not wasted. If the evidence supports optimization, they avoid a multi-year replacement program. If it supports replacement, they enter the market with requirements already written and defensible, which is the difference between a procurement that runs and one that stalls in evaluation.
That is the whole argument for sequence. The diagnostic is cheap and its output is reusable. The procurement is expensive and its output is a contract.
The uncomfortable version
There is a scenario public-sector leaders should be prepared for: the assessment comes back saying the platform you have been complaining about for three years is fine, and the problem is how your organization uses it.
That is a harder finding to carry to a board than “we need a new system.” It is also, in our experience, the more common one. An advisor with no implementation revenue and no software to resell can afford to deliver it. That structural detail is not a marketing line — it is the only arrangement under which you can trust the answer.
If you are weighing replacement against optimization and want the question answered before you commit to a procurement, schedule a briefing. Thirty minutes, no pitch. If we cannot help, we will say so.