How to Audit Your Technology Estate Before You Modernise
The GAO could rank the US federal government's legacy systems by risk because it actually looked — at age, language, hardware support and known vulnerabilities. Most organisations modernise the system that is loudest, not the one that is riskiest.
Most modernisation programmes start with the system that generates the most complaints, not the system that carries the most risk. Those are often different systems, and the difference matters because budget spent on the loud one is budget not spent on the dangerous one.
This is a companion piece to our legacy modernisation guide.
How the GAO actually ranked risk
The US Government Accountability Office's review of federal legacy systems is a useful model precisely because it used explicit, checkable criteria rather than impressions. Of 69 systems reviewed, it identified 11 as most critical based on factors including: age (23 to 60 years), whether the system ran on an outdated programming language (true for 8 of 11), whether it ran on hardware no longer supported by the vendor (true for 4 of 11), and whether it had a known cybersecurity vulnerability (true for 7 of 11). (GAO-25-107795)
Notice what is not on that list: how frequently users complain about the system, or how outdated its interface looks. Those things matter for a different reason — usability and productivity — but they are not what makes a system dangerous to keep running. An estate audit should score for danger and for annoyance separately, because they call for different responses.
What an estate audit should actually check
Language and framework support status. Is the system built on a language or framework still receiving security patches? A system in an unsupported language is not merely old-fashioned — it is a growing security liability with every month that passes, because vulnerabilities discovered after support ends will never be fixed by the vendor or community.
Hardware and infrastructure dependency. Does the system depend on hardware the vendor no longer supports, or that is becoming difficult to source replacement parts for? This risk compounds silently until the day something fails and no replacement exists.
Known vulnerabilities, checked rather than assumed absent. Has the system actually been scanned for known vulnerabilities recently, or is "we haven't had a problem" being treated as evidence of security rather than an absence of looking?
Concentration of institutional knowledge. How many people currently understand this system well enough to safely change it? A system understood by exactly one person is a risk regardless of its age, and a system understood by several people spread across a team is lower risk even if it is old.
Actual change frequency and cost. How often does the business need to change this system, and how long does a typical change actually take compared to a modern equivalent? A stable system that rarely needs to change carries different economics than one the business is constantly trying to extend.
Data quality, profiled rather than assumed. As covered in our piece on data migration risk, legacy data accumulates undocumented drift over years of real use. An estate audit should include at least a lightweight data profiling pass on the systems being considered for modernisation.
Turning the audit into a prioritised list
Score each system against the criteria above, then look for the combination that matters most: high risk and low cost to remediate. A system with a known vulnerability that could be addressed by a contained rehosting project is a better first target than an equally old system whose remediation requires a full rebuild, even if the second system feels more urgent because users complain about it more.
This is also where the rewrite, refactor or replace decision gets made system by system, rather than assuming every legacy system in the estate deserves the same treatment. Most estates contain a mix: some systems need full replacement, many need only a contained intervention, and some genuinely do not need to be touched yet.
Why this order of operations matters economically
McKinsey's 2020 survey of CIOs at large financial services and technology firms estimated technical debt at 20-40% of technology estate value before depreciation, with 10-20% of new-product budget diverted to servicing it. (McKinsey) A budget spent modernising the wrong systems first does not reduce that diversion — it just moves the diverted money to a different project while the actual risk sits untouched.
What we do
Before recommending any modernisation programme, we run a structured audit against the criteria above and present a ranked list, not a single recommendation. Which system gets fixed first is a decision the client makes with real information, not one we make for them based on which system happens to be the noisiest.
If you are trying to work out which parts of your technology estate genuinely need attention first, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source.