Insights / Modernization

Old Software: Fix It, Replace It, or Leave It Alone?

Old doesn’t automatically mean bad. Here’s how I help businesses decide whether an aging system needs a repair, a replacement, or nothing at all.

· 4 min read

Watson’s Mill, a historic stone grist mill in Manotick, Ontario

Most businesses have at least one system everybody complains about. It’s old, it looks dated, and only one or two people really understand it. The natural reaction is to want it gone. Sometimes that’s the right call. Often it isn’t, or at least not yet.

The question I try to answer isn’t “is this system old?” It’s “is this system still doing its job at a cost the business can live with?”

Start with what’s actually going wrong

I like to begin with the problems people can describe in their own words. A simple change takes weeks. The reports don’t match what’s on the shelf. Everything stops when one particular person is on vacation, because they’re the only one who knows how month-end works. The system went down twice last quarter and orders piled up.

Those are useful, because they tie the software to real time and real money. “It’s old” isn’t on that list. A ten-year-old system that rarely needs changing can be cheaper to keep than to replace. And a system built two years ago can already be a problem if the business has changed around it.

Add up what it really costs to keep

The cost of an old system is much more than the hosting bill. It includes:

  • the hours people spend on workarounds and typing the same thing twice
  • projects that get delayed because the system is hard to change
  • downtime, and the scramble that comes with it
  • security risk if the system can no longer be updated
  • how hard it is to find someone who can look after it

These costs are usually spread across several departments, so nobody sees the full total. A short review fixes that. List the most important jobs the system does, who relies on it, what keeps breaking, and what the business expects to need over the next two or three years. Rough numbers are fine. Just be honest about which ones are guesses.

You have more than two options

It’s rarely a straight choice between doing nothing and rebuilding everything. In between, you might:

  • fix the one part that causes most of the pain
  • replace a single piece, such as the reporting or the link to your accounting software
  • put a clean, modern layer around the hard-to-change part so newer tools can work with it

Small steps aren’t always the answer, though. If the data inside the system can’t be trusted, or the system simply can’t do what the business needs next, patching it can just drag the problem out. The point is to choose deliberately rather than out of habit.

The unwritten rules are the hard part

When you replace a system, rebuilding the screens is the easy bit. The hard bit is all the small rules nobody wrote down: the customer who gets a special price, the order that’s allowed to skip a step, the export someone in accounting relies on every Friday. Those details are often the real heart of the system.

Before moving to anything new, I want to know where the trusted data lives, how duplicates and old records will be handled, and how we’ll prove the new system gives the same right answers. It’s also worth planning how to switch back if something goes wrong, and whether to run the old and new systems side by side for a while. A good plan explains how you’ll know the data is correct, not just how it gets copied across.

Five questions before deciding

Before I recommend anything, I want answers to five questions:

  1. What specific problem are we solving?
  2. What does it cost, and what’s the risk, if we leave things as they are?
  3. Which limits are truly fixed, like budget, deadlines, or regulations?
  4. How will we check that the new approach works properly?
  5. What’s the smallest useful step that lowers the risk without boxing us in later?

If those answers are fuzzy, the right next step is usually a short review with a fixed end date, rather than a big project. You should come out of it with a clear map of your systems, the main risks in order, realistic options, and a sensible order to tackle them in.

The bottom line

Updating old software isn’t about chasing new technology. It’s about making sure the system can keep supporting the business. Sometimes that means a rebuild. More often it means a few targeted fixes, better visibility, and a safer way forward.

← All insightsTalk to me about your system