A legacy system assessment is a structured look at the applications you run, scoring each one on what it's worth to the business and how risky it has become to change. Done across the whole portfolio, it tells you which application to worry about first and which ones you can safely leave alone.
Many published frameworks for this are built for large consulting programs, with dozens of weighted criteria. This one is smaller on purpose: two axes, eight questions, each scored from 1 to 5, and a short ranked list of where to look next.
- Score every application from 1 to 5 on two axes: how much the business depends on it, and how safely it can be changed today.
- A manager, the business owners and the lead developers can score a whole portfolio in an afternoon. The ranking matters more than the decimals.
- High value with poor health is the corner to act on first. Low value with good health can be left alone.
- The matrix tells you where to look. It can't tell you what's inside the worst application. Only reading the code does that.
Start with a list of what you actually run
You can't score what you haven't listed. Write down every application the business relies on, including the ones IT never built, such as the Access database that calculates commissions. For each one, note:
- what it does for the business, in one sentence;
- who owns it on the business side;
- who can change it on the technical side;
- what it runs on (language, database, operating system, any vendor package);
- whether each of those layers is still inside vendor support.
A line you can't fill in is already a finding. For what an unsupported layer means in practice, see the risks of running end-of-life software.
How do you assess a legacy system?
Score it on two axes separately. Business value asks how much it would hurt if the application stopped, or couldn't change when the business needed it to. Technical health asks how safely and quickly it can be changed today. An application can be critical and fragile at the same time, and that combination is what you're looking for.
Use whole numbers from 1 to 5 and average each axis. An average above 3 counts as high value or good health. Anything at 3 or below counts as low value or poor health, because looking and finding nothing costs less than skipping the one that needed attention.
Business value: three questions
| Question | Score 1 when | Score 5 when |
|---|---|---|
| How many people or processes depend on it? | A few users, with a workaround if it stops | A core process stops without it |
| What revenue or compliance exposure does it carry? | None, it's an internal convenience | It bills customers, holds regulated records or feeds a filing |
| How often does the business ask for changes? | Rarely, and nobody minds waiting | All the time, with a queue of requests |
Technical health: five questions
| Question | Score 1 when | Score 5 when |
|---|---|---|
| Is everything it runs on inside vendor support? | A layer is past end of support with no paid option | Every layer is current |
| How many people can change it safely? | One person, or nobody | A team, with no single point of failure |
| Are there tests the team trusts? | No automated tests, or tests everyone ignores | A trusted suite runs on every change |
| How painful is a release? | Manual, rare, and everyone holds their breath | Routine, mostly automated and easy to roll back |
| How exposed is it to security problems? | Internet-facing, unpatched, shared logins | Patched, access reviewed, exposed no more than it needs to be |
Where the business owner and the developer disagree on a score, write down why. That disagreement is often the most useful thing the exercise produces.
The legacy system assessment matrix
Plot each application with value on one axis and health on the other. That gives you four corners, and each one comes with a default answer.
| Corner | What it usually looks like | What to do |
|---|---|---|
| High value, poor health | The system the business can't run without and nobody wants to touch | Act first. Look inside it before deciding anything |
| High value, good health | Core systems that are well understood and change safely | Maintain and invest, so they stay in this corner |
| Low value, poor health | Old tools few people use, often on platforms past support | Retire or replace. Check who still uses them first |
| Low value, good health | Small, stable utilities | Leave them. Score them again next year |
Here's how that looks for a made-up portfolio. The scores are illustrative.
| Application | Value | Health | Corner |
|---|---|---|---|
| Order management system | 4.7 | 1.8 | Act first |
| Customer portal | 4.0 | 3.8 | Maintain and invest |
| Old warehouse reporting tool | 1.7 | 2.0 | Retire or replace |
| Meeting room booking app | 1.3 | 4.2 | Leave it |
Don't argue over decimals. The matrix exists to rank, not to measure.
Two corners need a warning. Health slips quietly, so a well-kept core system can drift into the worst corner unless someone budgets for upgrades before a support date forces one. And before retiring a low-value tool, check for hidden dependencies, such as a nightly file another system expects to find.
Who should run a legacy system assessment?
The IT director, CTO or head of engineering should own it, but not score alone. Business owners answer the value questions and maintainers answer the health questions. Keep this portfolio scoring in-house, because the people who live with these systems know things an outsider won't pick up in an afternoon. Outside help earns its place one step later, on the application in the worst corner.
Last step: look inside the worst one
The matrix ranks applications by what people believe about them. Before anyone chooses between upgrading, wrapping, replacing or rewriting the one in the worst corner, someone has to read the code and find out:
- what the application really does, including the business rules nobody wrote down;
- what depends on it, and what it depends on;
- where the architecture makes change hard;
- which security and compliance gaps exist;
- who understands which parts.
That's a different kind of work from scoring. Our code audit checklist and software architecture review checklist cover what that review should look at, and legacy system modernization sets out the options. If one person holds most of what's known about the system, start capturing that knowledge now.
When to bring in the 30-day assessment
The matrix is something you do yourselves, across every application you own. The 30-day assessment is something we do on one of them, usually the application in the high value, poor health corner, once you've agreed it matters enough to look at properly.
It's fixed in scope, at a price agreed before we start. Over 30 days we go through that application's codebase and the architecture around it, map how it fits together with the systems it feeds and depends on, find the hidden architectural debt, and flag the security and compliance gaps. Questions you scored from experience, such as how far the tests can be trusted and where change is hardest, get checked against the code itself.
The report says in plain language what is broken and what it would take to fix it. Your own team can act on it, or we can do the work as a separate project with its own scope and price. Either way, the report stands on its own.