Most owners know, somewhere at the back of their mind, that their software is becoming a liability. What they usually lack is a way to turn that uneasy feeling into something specific enough to act on. This checklist is that. It walks through eight areas, in plain English, with what to look for in each — so that by the end you have a clear picture rather than a vague worry, and any decision about what to do next is a deliberate one rather than a leap of faith.
You do not need to be technical to run it. Where an answer needs someone who knows the system, the honest discomfort of asking the question — and noticing how hard it is to get a straight answer — is itself part of the assessment.
The eight areas, and what to look for
Work through each area and note where you land. There is no score to total up; the value is in seeing how many red flags cluster together.
| Area | What to look for | Red flag if… |
|---|---|---|
| 1. Performance | How the software behaves under a normal day’s load — speed, reliability, the number of “it’s being slow again” complaints. | It slows down at busy times, falls over under load, or staff have learned to work around it (“do that report first thing before it gets slow”). |
| 2. Integrations | How your systems talk to each other — CRM, accounts, ordering, spreadsheets — and whether data flows automatically or by hand. | People re-key the same data between systems, or things sync overnight by export rather than in real time. Manual re-keying is one of the clearest signals of all. |
| 3. Manual work | The steps a person performs only because the software cannot — copying, reconciling, chasing, stitching reports together. | A month-end (or week-end) ritual exists purely to reconcile what the systems should have agreed on by themselves. |
| 4. Cost | What the software actually costs to run — hosting, licences, and the staff time spent keeping it alive. | The bill rises faster than usage, or a surprising amount of someone’s week goes on keeping the lights on rather than improving anything. |
| 5. Legacy risk | How old the core system is, whether it still gets updates, and how dependent you are on it. | It runs on software the vendor no longer supports, or on hardware you could not easily replace. “Old and business-critical” is the precise definition of a legacy risk. |
| 6. Security | Whether the system is patched, supported and recoverable — and whether your backups have ever actually been restored. | It runs unsupported software (no more security updates), or your backup has never been tested by a real restore. You discover an untested backup only while trying to use it. |
| 7. Documentation & knowledge | Whether how the system works is written down — or lives only in someone’s head. | One or two people “just know how it works”, and a holiday, illness or resignation would leave you genuinely stuck. Concentrated knowledge is a single point of failure. |
| 8. Growth | Whether the software helps or hinders where the business is going — new products, more customers, new channels. | You avoid or delay changes because the system makes them slow, risky or expensive — the software is now steering the business rather than serving it. |
A few of these deserve a word, because they are the ones owners most often under-weight.
The signals that matter more than they look
Manual re-keying (areas 2 and 3) is the quiet one. It rarely shows up as a crisis; it shows up as a person, or several, spending part of every day copying data the systems should have shared. It is expensive, it is error-prone, and it is almost always a sign that you do not have broken software — you have good tools that were never wired together properly. The cost is real but invisible, which is exactly why it gets tolerated for years.
The “only one person understands it” problem (area 7) is the one that turns a manageable situation into a dangerous one. When the understanding of a critical system lives in one or two heads — often people who have been there longest — their departure takes the design rationale, the hidden assumptions and the workarounds with them. It is worth being honest with yourself about how exposed you are here, because it is the cheapest risk to start fixing and the most expensive to leave.
And the missing safety net (area 6) underpins everything else. The reason changing old software feels dangerous is usually that there is no automated way to tell whether a change broke something — so every change is a bet, and people rationally stop placing them. That fear of change is not timidity; it is a correct response to an untestable system. The good news is that it is fixable: a test safety net can be built onto a system that never had one, and it is the single most valuable thing to do before changing anything.
What to do with the result
The honest reading of this checklist is not “any red flag means rebuild”. The opposite, in fact: a big-bang rebuild is the riskiest response and the one most likely never to finish. The point is to see the pattern. A clean run across all eight areas means your software is serving you; carry on. A flag or two means specific, contained improvements — a connection here, a backup test there. A cluster of flags, especially across legacy risk, security, knowledge and growth together, means the system is becoming a brake on the business, and it is worth a proper assessment before it forces your hand.
You don’t have broken software — you have good tools that were never wired together properly.
Frequently asked
- How do I know if my software actually needs modernising?
- Run this eight-area checklist — performance, integrations, manual work, cost, legacy risk, security, documentation, and growth — and note where you land in each. A red flag or two means contained fixes; a cluster of flags, especially across legacy risk, security, knowledge and growth, means the software is becoming a brake on the business and is worth a proper assessment.
- Does a failing checklist mean I have to rebuild everything?
- No. A big-bang rebuild is the riskiest, least-likely-to-finish response. Most red flags point to specific, contained improvements — connecting two systems, testing a backup, capturing knowledge that lives in one person’s head. The checklist tells you where the risk is, so the next step is deliberate rather than a leap.
- Which warning sign matters most?
- The two most under-weighted are manual re-keying between systems (a sign your tools were never wired together) and “only one or two people understand it” (concentrated knowledge is a single point of failure). The missing test safety net underpins both, because it is what makes any change feel dangerous.
- Can I run this without being technical?
- Yes. The questions are deliberately in plain English and most are about how the software behaves and how your people work around it. Where an answer needs someone who knows the system, noticing how hard it is to get a straight answer is itself a useful part of the assessment.
If you would like this done properly — the same eight areas, scored and explained, with a clear sense of what is worth doing and what is not — that is exactly what our free assessment provides. Start it at /application-modernisation/free-assessment.