The most expensive thing in a system replacement is a requirement nobody can see.
Not a missing one — those get found. Not a wrong one either; those turn up eventually, usually painfully. The expensive kind is the requirement that was understood correctly, implemented as well as 2003 allowed, and has been quietly shaped by that limitation ever since. Batch because real-time wasn’t available. A nightly file transfer because there was no API. A single value where the business actually needed several.
Nothing about it is broken. That’s the problem.
There are three independent ways this kind of requirement stays hidden through legacy system modernization, and they all point the same direction.
Users describe the workaround. Ask a caseworker what the system should do and you’ll get an accurate, detailed description of the current process. They were trained on the constraint. It isn’t experienced as a compromise — it’s experienced as the job. You will not find a constrained requirement by interviewing the people who work around it daily, because to them there’s nothing to work around.
Code analysis confirms the compromise. Read the code and you get a correct description of a constrained implementation. There’s no anomaly to flag; the system is internally consistent. AI-assisted comprehension is genuinely useful here — it will read an undocumented legacy application faster and more thoroughly than a team of analysts, and it will faithfully describe the wrong thing.
Conversion tooling optimizes for fidelity. Preserving behavior is the entire point. On this category, preserving behavior is the failure mode.
Put those together and you get a program that runs a rigorous discovery process, produces accurate documentation, picks capable tooling, and spends three years building a modern implementation of 2003’s technical limits. Everyone involved did their job correctly.
The three kinds of requirements debt
We talk about technical debt constantly and requirements debt almost never. And it isn’t one thing.
Missing. The system never did something it should have. The gap got absorbed into a manual process, a shadow spreadsheet, a workaround. Everyone adapted. Eventually nobody remembered it was a gap.
Wrong. The system does something, but what it does is a workaround that hardened into a rule. The field labeled “comments” that determines whether a case gets approved. The status code that means something other than its name. The date stored as text because of a conversion problem in 2009. In the code this is indistinguishable from a requirement, which is exactly why it gets carried forward.
Constrained. The requirement was right. The implementation was as good as the technology allowed. This is the largest category and the one the three blind spots above are built for. It shows up constantly in ERP modernization work, where decades of workarounds get mistaken for the actual specification.
Most modernization discovery programs are scoped to reproduce what exists. What exists is frequently not what anyone intended.
Questions that actually surface it
The general form is “what would this do if the constraint didn’t exist.” That’s a principle, not a method. The method is more boring and more useful — a set of questions you run against the system, with someone who has worked it for fifteen years in the room:
For every batch process: what decision is waiting on this to finish? If the answer is a person or a downstream process, you’ve found a real-time requirement that was implemented as overnight.
For every single-value field: did the business ever need more than one? Multi-select was expensive in a lot of platforms for a long time. The workaround was usually a second field, a delimiter, or a policy that the answer can only be one thing.
For every manual step between two automated ones: what couldn’t the system do? Manual steps in the middle of automation are almost never a design choice.
For every field whose name doesn’t match its use: when did that start, and what was unavailable at the time? The answer dates the constraint and usually names it.
For every scheduled job: why that schedule? “Because it’s always run at 2am” often means the window was chosen around a mainframe contention problem that stopped existing in 2015.
None of this requires special tooling. It requires asking, and not accepting “that’s how the system works” as an answer — a discipline that matters as much in state and local government IT modernization as anywhere else, where legacy platforms tend to run decades past their original design intent.
The discipline that keeps this from becoming scope creep
“The old system was constrained, let’s reimagine it” is the sentence that precedes a three-year overrun. Identifying the categories is not permission to fix all of them.
Missing functionality with legal or mission consequence goes in scope. It’s an obligation, not an improvement.
Wrong functionality gets corrected. Carrying a workaround into a new system is worse than leaving the old one alone — now it has a fresh coat of paint and another twenty years of life.
Constrained functionality gets a deliberate, documented decision. Some is worth reimagining now. Most should be recorded, deferred, and revisited once the new platform exists and the cost of change is low.
The discipline is documenting the difference between “we know this is a compromise and we’re accepting it” and “we are fixing this in this release.” A program that can’t articulate that difference will try to fix everything and finish nothing.
It also gives the program manager something worth having: when someone asks in year two why a capability wasn’t included, there’s a record showing it was identified and consciously deferred. Better conversation than discovering it was never noticed.
The question to ask first
Legacy system migration and modernization is almost always scoped as rebuilding what we have. Reasonable instinct — it bounds the work, it’s defensible in a budget hearing, and it feels like the conservative choice.
It also guarantees you inherit every accommodation the last thirty years required.
The question worth asking before the requirements document gets written: what would we have built if we could have?
Then decide, deliberately, how much of that gap this program is going to close.
If you’re scoping a system replacement — or you’ve been deferring one because the discovery cost was hard to justify — that’s the conversation we’re built for. Get in touch today!