Free tool · Legacy systems

Legacy system risk scorecard

Ten questions about the system your business runs on. Answer them honestly and see a rough risk score, your three biggest risks and one concrete next step for each. Most of these risks are cheap to close while the system still works.

1. Has the developer who built the system left, or become hard to reach?

2. Is there only one person who can make a change and put it live? Count anyone, inside the business or out, who could do it safely next week without that person.

3. Is the code the only documentation, or is what's written down years out of date?

4. Has nobody ever restored a backup to prove it works? Seeing that backup files exist doesn't count. A restore means bringing the system up from one on another machine.

5. Is the source code held only by a developer or vendor, not in a repository the business controls?

6. Does it run on an operating system or database past its end of support? For example, Windows Server 2012 R2 (extended support ended October 2023) or SQL Server 2014 (July 2024).

7. Would you only find out it's down when staff or a customer tells you?

8. Do changes go straight onto the live system without being tried on a copy first?

9. Does it all run on one server, with nothing ready to take over if it fails?

10. When something breaks, does it take days to get a response from whoever supports it?

Your score

Answer all ten questions to see your score. 0 of 10 answered.

The developer who built it is gone or hard to reach.
While they are still reachable, pay for a handover session and get every login and the deployment steps written down. Ask yourself what would be at risk if they gave two weeks' notice today. What happens when they leave →
Only one person can change it.
Have a second developer put one small change live using only written steps. Wherever they get stuck is what to write down next. 5 warning signs your system needs attention →
The knowledge lives in someone's head.
Ask whoever maintains the system for a handover document. Start with access and credentials, then how a change goes live and how to roll it back. The handover checklist →
Your backups are untested.
Restore a recent backup to a separate machine, bring the whole system up, open a recent record and time it. That time is your real recovery time. How to run a restore test →
The business doesn't hold its own source code.
Get a complete copy into a repository registered to the business, and have another developer confirm it builds and runs. Check that your contract assigns the code to you. Who owns your source code →
It runs on unsupported software.
Find the exact Windows Server and SQL Server versions, and check them on Microsoft's lifecycle pages. If they are past end of support, plan the upgrade before an incident forces it. Windows Server and SQL Server end of life →
Nobody is warned when it fails.
Set up an alert for when the system or its backup job fails, sent to an address the business controls rather than one person's inbox. Warning signs of a system about to break →
Changes go live untested.
Write down how a change goes live and how to roll it back, then try each change on a copy of the system before it reaches the live one. Living in fear of deployments →
One server, no standby.
Decide how long the business can afford to be down. At the least, keep backups off that server and off the site, so one failure can't take the system and its copy together. Two numbers every owner should know →
Support is slow to respond.
Make sure every login, from hosting and domain to database and code repository, is in the business's name and written down, so someone else could step in. The emergency recovery guide →

A rule of thumb, not an audit. The questions, weights and next steps come from what we find when we take over legacy systems, written up in the SteadyDevs blog; the weights are our judgement, not an industry standard. Support dates checked on 23 October 2026 against Microsoft's lifecycle pages for Windows Server 2012 R2 and SQL Server 2014. Your answers stay in your browser.

How the score works

Each question has a weight, and the weights add up to 100. “Yes” scores the full weight, “Not sure” half of it and “No” nothing. Scores under 20 are low, 20 to 44 moderate, 45 to 69 high and 70 or more critical. The heaviest weights go to the risks that leave you with no way back on a bad day.

Risk	Weight	Why it matters
Backups never restored	14	An untested backup is a hope. Many businesses find theirs broken only when they need it.
Developer gone or hard to reach	12	A 20-minute fix becomes days while someone new learns the system.
Only one person can change it	12	You have a working person, not a working system.
Source code not in the business's hands	12	Without the code, bugs can't be fixed and nothing can change.
No usable documentation	10	A developer who has left can't explain what they meant.
Unsupported operating system or database	10	Security patches stop, while the software keeps running as if nothing changed.
No monitoring or alerts	8	Failures, including backup failures, go unnoticed for months.
Changes go live untested	8	Every change is a gamble on the live system.
One server, no standby	7	One hardware failure means days to rebuild, not an hour to switch over.
Slow support	7	Small problems wait, and grow while they wait.

Common questions

Is this scorecard an audit of my system?

No. It is a rule of thumb built from the problems we see most often when we take over legacy systems. It can't see your code, your server or your backups, so a low score doesn't prove the system is safe and a high one doesn't mean it is about to fail. Use it to decide what to check first.

Why does “Not sure” count against me?

Because not knowing is itself a finding. If nobody can say when a backup was last restored or which server version the system runs on, nobody is looking after it. “Not sure” scores half the weight of “Yes”, and finding out is the first step.

What should I fix first?

Usually access, code and data: make sure the business holds every login, a complete copy of the source code and a backup it has actually restored. Those are what you need on the day something goes wrong. The scorecard lists your top three in order of weight.

The system works fine. Why should I worry?

Working fine and about to fail often look the same from outside. Systems send warning signs for months before they fail, and fixing them on your own schedule is far cheaper than fixing an outage. Read the warning signs.

What does the free assessment involve?

You describe the system and the problem. We reply within 1 to 2 business days, hold a free 30-minute strategy session, and send a written assessment with a fixed quote. There is no charge and no obligation to proceed.

Next step Want someone to look at the system itself? The System Health Check is a RM399 fixed-price review of your codebase and top risks, with a written assessment and prioritised recommendations. Or start with a free strategy session →