Replace the old system everyone's scared to touch.
Replacing legacy software before the one PC it runs on gives up
There's an old database on a PC under someone's desk, or a system whose developer retired years ago, and half your business runs on it. We get your data and your rules out of it, and build something you can use from any phone, with backups and an owner.
It's probably fine. Until it isn't.
Old systems often work remarkably well, which is why they're still there. Somebody built it years ago, it knows your business, and everyone has learned its funny little ways. The trouble is rarely the software on a normal day. It's what you'd do on the day it stops.
It's worth a proper look if it only runs on one ageing computer, if only one person really understands it, if nobody can remember who built it, or if you've had to keep an old version of Windows or Office around just to open it. The same goes if staff can't use it from home, or from a van.
What we get out of it.
An old system is usually worth more than it looks, because years of decisions are buried in it. Our first job is to get those out safely, without breaking what you've got.
Your data.
Customers, jobs, prices and history, copied out and checked. Old data tends to be messy, with the same customer spelt four ways, so we tidy it as it comes across and show you what we changed.
Your rules.
The sums, the discounts and the "never do this on a Friday" logic. Some of it's written into the old system, and some is only in someone's head. We go through both, with the person who knows.
Your reports.
If someone relies on that one printout every Monday, it needs to still exist. We list what actually gets used, keep those and let the forgotten ones go.
What people have learned.
Every old system has its workarounds, and they tell you exactly what it should have done. We sit with the people who use it, because the best specification for the new one is watching them use the old one.
How we replace it without stopping the business.
We don't turn anything off on day one. We usually start with a full copy of the old data and the part of the system that hurts most, build that first, then get it into daily use. The old one keeps running beside it until everyone's happy.
Once the new part has proved itself, we move the next bit across. Before each step, we compare the new system's numbers against the old one's, using real past records. Where they disagree, either we've got something wrong or the old system has been wrong for years. Both are worth knowing.
What you end up with.
A system you open in a browser, on a phone in a van as easily as on the office PC. It has backups that run themselves, logins for each person, and a record of who changed what. The running costs go on accounts in your name.
You own the code, and it's written in common tools with plain notes, so you're never again depending on one person's memory, including ours. If what you really need turns out to be a good off-the-shelf app, we'll say so, and help you get your data into it.
Questions about replacing old software.
Can you get data out of an old Access database or unsupported system?
Usually, yes. Access databases can normally be opened and read, even very old ones. Other systems may need more detective work, such as exports, reports or reading the database files directly. We'd take a copy and try it before quoting, so you'd know what's possible and you wouldn't be paying on the strength of a guess.
What if we don't have the original code or the developer has gone?
That's common, and it doesn't usually stop us. We don't need the old code to build something new. What matters is your data and an understanding of what the system does, and we can get that from the data, the screens and the people who use it. If you can't get into the data at all, we'd tell you early.
Do we have to stop using the old system while you build the new one?
No, and we'd advise against it. The old one keeps running until the new one has proved itself on real work. We usually move a part at a time, and copy across anything that's changed just before each switch. It means a short spell of running both for that part, but nothing like the risk of a big-bang changeover.
It still works. Do we really need to replace it?
Maybe not yet. If it's stable and you can restore it from a backup, there's no rush, and we'd tell you that. The sensible first step costs little: take a proper backup, write down how it works and who knows it, and plan for the day it stops. Replacing it on your timetable is much cheaper than replacing it in a panic.
How much does it cost to replace old software?
It depends how much the old system does and how messy the data is. We'll look at what you've got and go through it with the people who use it, then give you a fixed price in writing, often for the most important part first. Compare it with what it would cost you if the old system stopped next Monday.
What if our old system is really just a big spreadsheet?
Then you're in very good company. Plenty of businesses run on a spreadsheet that's grown into a system, with macros nobody dares to edit. The approach is the same: get the data and rules out, and build the part that hurts first. We've written a separate guide on spotting when a spreadsheet has become a system.
Replacing old software for your trade.
Some of the trades we build for. Or see everyone we help.
Got something that's slowing you down?
Tell us what's eating your time, in your own words. We'll tell you honestly whether we can help, and what it would take.