This is the guide I'd give an owner who has just realised the system at the centre of the business is old, a bit fragile, and understood by one person (who may or may not still answer the phone).

What counts as legacy software?

It isn't about age on its own. Plenty of old software is fine. It becomes a legacy problem when one or more of these is true:

  • The platform underneath it is out of support. No more security fixes from the people who make it.
  • Only one person understands it. Often the developer who built it, sometimes someone who left years ago.
  • Changing it is scary. Small requests take weeks because nobody's sure what else will break.
  • It can't talk to anything modern. No API, so people copy data between systems by hand.

The usual suspects: old PHP sites and apps (often built on CodeIgniter 2 or 3), Microsoft Access databases that grew into the company's main system, Visual Basic 6 desktop apps, and the occasional COBOL system that genuinely still runs the money.

The risks of leaving it alone

Security. PHP is a good example because the dates are public. According to php.net, PHP 8.1 stopped getting security fixes on 31 December 2025, and 7.4 back in November 2022. PHP 8.2 gets its last security fixes at the end of this year, on 31 December 2026. If your app runs on anything older than 8.2, any new hole found in PHP itself won't be fixed for you. Ever.

Visual Basic 6 is a similar story. Microsoft still keeps the VB6 runtime working on current Windows, but its support is limited to serious regressions and critical security issues, the development tools haven't been supported since 2008, and Microsoft's own advice is to replace these applications with modern technology.

Key-person risk. This is the one that actually bites most small businesses. The code might be fine. The problem is that it lives in one person's head. If they leave, retire or get poached, you're left with a system nobody can safely change.

Slow, expensive change. When every tweak is risky, people stop asking for tweaks. They build spreadsheets around the system instead. That hidden workload is often the biggest cost of legacy software, and it never shows up on an invoice.

Your five real options

There's no single right answer. Here's what each option involves, roughly in order of how much it disrupts the business.

1. Keep it running, safely

Sometimes the honest answer is that the software does its job and you shouldn't touch the business logic at all. What you can do is make it safer: move it onto a supported server and PHP version, get proper backups (that you've actually tested restoring), lock down who can reach it, and get the code documented so it no longer lives in one head.

This is the cheapest option and buys you time. It doesn't fix the "nobody dares change it" problem, but it removes the worst risks. It's also the sensible first step before any of the other options. Our software support and maintenance work starts here, whoever built the system.

2. Refactor in place

Keep the system, but improve it from the inside. Upgrade the framework and language version, add tests around the important bits, tidy the worst code, and fix the slow database queries. For an old CodeIgniter app, that might mean upgrading the PHP version it runs on, or moving from CodeIgniter 3 to 4, which is a proper rewrite of parts of the app rather than a quick upgrade.

Good when the system is basically sound and still fits how you work. The users barely notice anything changed, apart from it getting quicker and less fragile. There's more on how we approach older CodeIgniter applications on our CodeIgniter page.

3. Replace it piece by piece

Build the new system alongside the old one and move one area across at a time. Orders first, say, then stock, then reporting. Both systems share data while the switch happens, so there's never a big-bang weekend where everything changes at once.

This is usually my favourite option for systems that run the business. The risk is spread out, you get value from the first piece in weeks rather than months, and if something goes wrong you've only moved one part.

4. Rebuild it

Start fresh and move everything over at the end. It's the cleanest result but the riskiest route. The hard part is rarely the new code. It's finding all the rules the old system quietly enforces that nobody wrote down, and getting the data across cleanly.

A rebuild makes sense when the old system is so tangled that improving it costs more than replacing it, or when it's built on something you genuinely can't support any more (COBOL is the classic example, and we've written about COBOL modernisation separately).

5. Buy something off the shelf

If the old system does something common (accounts, CRM, a helpdesk), a modern off-the-shelf product might do it better and cheaper. Be honest about how much of your process you'd have to bend to fit it, and what you'll pay per user per year once everyone's on it. I've written a longer bespoke vs off-the-shelf guide if you're weighing that up.

How to decide

Three questions get you most of the way:

  • Does the software still fit how the business works? If yes, lean towards keeping or refactoring. If people have built workarounds all over it, lean towards replacing.
  • How much risk can you stomach right now? If the system takes the money, piece by piece beats a big rebuild almost every time.
  • Is anything you need commodity? Don't pay to rebuild your own accounts package.

Whatever you choose, start with option one. Get it onto supported versions, backed up and documented. Then decide calmly, rather than during an outage.

Has AI changed the maths?

Yes, honestly, but not in the way the hype suggests.

AI-assisted development has made the typing part of a rebuild much faster. It's also very good at reading old code and explaining what it does, which helps with the "nobody knows the rules" problem. That shifts the balance: rebuilding or replacing piece by piece is now cheaper than it was a couple of years ago, so it's worth getting a fresh quote even if you were put off last time.

What AI doesn't do is understand your business, spot the rule that only matters at year end, or take responsibility when the stock figures are wrong. Every line still needs review by someone who understands it, and the important flows still need proper tests. The saving is real, but it comes from experienced people working faster, not from skipping the careful bits.

Where to start

If you're not sure what you've actually got, that's the first job. A look over the code, the server it runs on and the versions underneath it will tell you which of these five options are realistic, and how urgent it really is. Usually it's less dramatic than people fear, and occasionally it's more.

If you'd like us to have a look, get in touch and you'll be talking to Rob or Jason, the people who'd actually do the work.

Cheers, Rob