If your business depends on a system nobody fully understands, the risk is not that it stops working tomorrow. The risk is that when it does stop, nobody can fix it quickly. The practical answer is to write down what the system actually does, work out which parts the business can't operate without, and then replace or rebuild it in stages while the old one keeps running. You don't have to rip it out in one go, but you do need a plan before it breaks.
It might be an Access database built by someone who left years ago, linked Excel workbooks with macros that break if you look at them wrong, or a custom program on a server under someone's desk. It works, mostly. Until it doesn't, and the only person who knew how it worked can't be reached.
The hidden risk of legacy systems
Old systems rarely fail all at once. They wear down slowly. The spreadsheet that takes minutes to open instead of seconds. The database that corrupts every so often and has to be restored from backup. The custom program that won't run on a current version of Windows, so one machine in the office is never upgraded.
Each of these is a warning sign that gets treated as normal. Staff build workarounds. Management accepts the limits because replacing the system feels too hard or too expensive. Meanwhile the risk grows quietly: the old machine is a security weak point, the backup may not restore, and every year fewer people know how the thing works.
Common patterns we see
- Access databases holding important business data, with no documentation and backups nobody has tested.
- Excel workbooks with macros that run key processes such as pricing, scheduling or reporting, built by a former employee.
- Custom software built on tools that are no longer supported, such as Classic ASP, Visual Basic 6 or FoxPro.
- Servers running old operating systems because one important program won't run on anything newer.
- Processes that live in one person's head, with nothing written down about how the system is used or what to do when it misbehaves.
If any of these sound familiar, our pages on Access database replacement and legacy system end-of-life migration go into more detail.
A practical path to replacing it
Replacing an old system does not always mean a full rebuild. Often the right approach is step by step.
- Write down what exists. Before touching anything, record what goes in, what comes out, the calculations and rules it applies, and which other systems it talks to. This step alone reduces the risk, because the knowledge is no longer in one person's head.
- Find the parts the business can't run without. What must the replacement do on day one? What can wait for a second stage? What does nobody use any more?
- Look at off-the-shelf options first. Many jobs that once needed a custom database can now be handled by standard online software, sometimes alongside your accounting system. Custom software makes sense when your process is genuinely different from what the packages assume.
- Plan the data move carefully. Data held in old systems is usually messy: duplicates, half-filled records, codes nobody remembers. Budget time to clean it as part of the move.
- Run old and new side by side. Never switch from old to new in a single day. Keep both running until the new one has proven itself through a full cycle of the work it supports, such as a month-end or a pay run.
Signs it is time to act now
Some situations move this from "one day" to "this quarter":
- The one person who understands the system is leaving or retiring.
- The computer it runs on is out of support, or a hardware failure would take it with it.
- Your accountant, auditor or insurer has asked questions about it.
- The business is growing and the system is slowing everyone down.
- You need to connect it to something new and can't.
If the person is leaving, document what they know before their last day, whatever else happens.
Frequently asked questions
Should we replace our Access database or rebuild it?
It depends on what it does. If a standard product covers the process, replacing it is usually cheaper to run long-term. If the database holds rules specific to your business that no package handles, a rebuilt custom system makes more sense. Write down what it does first, then decide.
Can we keep using the old system while we replace it?
Yes, and you should. Running both for a period is the safest way to prove the new system gives the same answers before you switch the old one off.
What is the first step if the person who built it has already left?
Start with what you can see: the screens, the reports, the files it reads and writes, and what staff do with it each day. Someone experienced with older tools can then open the system up and document the logic inside it.
How much does replacing a legacy system cost?
Costs vary widely depending on the size of the system, how much data needs to move and how much needs to be custom-built, so we scope every project first and give a fixed quote after a free initial chat.
If there's a system in your business that only one person understands, book a free initial chat and we can talk through where to start.