Your software is seven years old. Should you be worried?
Somewhere in your business there's a system that was built years ago. It does the quoting, or the job tracking, or the stock, and the office lives in it all day. It cost proper money at the time, it works, and nobody has looked underneath it since. Then something makes you wonder. A supplier goes quiet. An integration breaks. This week it was a worm crawling through npm, and a few people have asked us some version of the same question: is our old system a problem?
The honest answer is usually no, with an asterisk. This post is the asterisk. Five questions, an afternoon at most, no technical knowledge required, and at the end you'll know whether your system is fine, drifting, or genuinely urgent. Most land in the middle, and the middle is cheap to fix.
Software doesn't wear out
Code doesn't rust. A system that has run your operations for seven years isn't degrading in some physical sense, and its age alone tells you almost nothing. Plenty of banks run code that's older than the people maintaining it.
An old system that still fits your business is actually the expensive part, already paid for. Baked into it are years of decisions about how you really work. The weird discount rule for that one customer. The report the accountant needs in exactly that format. The way jobs get split when a crew is short. Nobody wrote those down anywhere else. A rewrite throws that knowledge away and pays to rediscover it, usually the hard way.
So the age isn't the question. The question is whether anyone is looking after it, because while the code stands still, everything around it moves.
What actually goes stale
The stuff underneath
Your system sits on a stack of things you never see: a language version, a framework, a database, a server operating system, and hundreds of borrowed packages of exactly the kind this week's npm worm targeted. All of it has an end-of-support date, and once that passes, security holes stay open forever. The UK's National Cyber Security Centre is blunt about this: flaws in unsupported products are exploitable by relatively low-skilled attackers. You can look up the support dates for almost anything at endoflife.date, which is a genuinely useful ten minutes.
The connections
Old systems rarely break on their own. They get broken by the world around them: a payment provider retires an API, a courier changes their integration, a certificate expires, an email service tightens its rules. Each one arrives as a surprise outage that was, in fact, announced in a newsletter nobody reads.
The people
The most common failure mode we see isn't technical at all. It's that exactly one person understands the system, and they've moved on, retired, or fallen out with the company. Sometimes the deploy process is a ritual that lives in their head. We have genuinely met the laptop that must never be turned off.
The escape hatches
Backups that have never been test-restored. Source code that only exists on the supplier's infrastructure. Admin credentials nobody can find. None of these matter until the one day they're the only thing that matters.
The five questions
You don't need to read code to answer these. You need an afternoon, and possibly a phone call to whoever built or hosts the system.
1. Who could safely change it, today?
Name an actual person. If the answer is one person, you have a single point of failure with a notice period. If the answer is nobody, that's your whole priority list right there.
2. Do you hold the source code?
Not "the supplier has it". You, in a repository or an escrow arrangement you can reach if the relationship ends or the supplier folds. It's your business logic; you paid for it. If you're not sure, ask. It's a normal question and a good supplier won't flinch.
3. Is what it runs on still supported?
Ask for the versions of the language, framework, database and operating system, then check them against endoflife.date. You're not judging the answers, just writing them down. "PHP 7.4, ended November 2022" is a fact you can plan around. Not knowing is the only bad state.
4. Has a backup ever been restored on purpose?
A backup that's never been test-restored is a hope, not a backup. Ask when the last test restore happened and what it proved. This one question has saved more businesses than any firewall.
5. If it went down at 9am Monday, what's the plan?
Who gets called, what do they need, and how long can the business run on paper? You're not writing a disaster recovery manual. You're checking whether the answer is a shrug.
Scoring it
Five confident answers: your system is old the way a well-kept building is old. Carry on.
Mostly "I'd have to check": you're drifting, which is the normal result and the cheap moment to act. Drifting systems are fixed with maintenance, not surgery. Dependencies updated on a schedule, a second person shown around the codebase, a test restore in the calendar, credentials rotated. A few days a quarter, roughly what you'd spend servicing a van, and it compounds the same way.
Mostly bad answers, on a system the business can't run without: that's urgent, and it's still very fixable. It's precisely the situation our project rescue work exists for, and the first step is a fixed-price assessment rather than a leap of faith.
A word about the rewrite pitch
Take your five answers to some agencies and the quote that comes back will be for a ground-up rebuild. Occasionally that's right. Usually it's the most expensive and riskiest option on the table, and it discards the very thing that makes your old system valuable: all those encoded years of how your business actually runs.
The alternative is to modernise in increments: stabilise the risky parts first, update the foundations piece by piece, keep the system running and earning the whole time. It's less dramatic. That's rather the point.
A good problem to have
An old system that still runs your business means the hard part is already done. Software that fits how you work exists, and it's yours. Looking after it costs less than replacing it, and far less than the week you'd lose finding out the backup didn't work. An afternoon with five questions will tell you which of those paths you're on.