Many established businesses rely on a piece of software that was built years ago, and sooner or later they have to decide whether to refactor, rebuild or replace legacy software like it. It might be an in-house database, an old web application or a heavily customised package that the original supplier no longer supports. It still works, mostly, but every change is slow and expensive, it does not run well on modern devices and there is a nagging worry about what happens if it breaks.
When that worry becomes serious, there are three broad options. Choosing the right one can save a great deal of money and disruption.
Option one: refactor
Refactoring means improving the existing code without changing what the system does. That might involve upgrading the programming language or framework to a supported version, tidying up the most fragile parts, improving security and adding automated tests so future changes are safer.
Refactoring makes sense when:
- The system still matches the way your business works.
- The underlying technology is old but not obsolete.
- The main problems are maintainability, security and performance rather than missing functionality.
It is usually the least disruptive option, because users carry on with the system they know.
Option two: rebuild
Rebuilding means creating a new system that does the same job, using modern technology, often with improvements along the way. Your data and the knowledge built into the old system carry over, but the software itself is new.
Rebuilding makes sense when:
- The technology is so old that finding developers or hosting is difficult.
- The system is too tangled to change safely.
- Your processes are still unique enough that an off-the-shelf product would not fit.
- You need things the old system cannot offer, such as mobile access or integration with other tools.
Photo by Dan Counsell on Unsplash
Option three: replace legacy software with an existing product
Replacing means retiring your custom system and moving to an existing product, such as a standard CRM, stock control or practice management package.
Replacing makes sense when:
- Your processes have become fairly standard over time.
- A well-supported product now does most of what you need.
- You would rather pay a subscription than own and maintain software.
The trade-off is that you will probably need to change some of the ways you work, and you are dependent on the supplier’s roadmap and pricing.
How to decide
A few questions help narrow down the options:
- What does the system do that nothing else does? If the answer is “a lot”, a rebuild or refactor is more likely to be right.
- How risky is the current setup? Unsupported software, no backups and only one person who understands it all increase urgency.
- What will you need in three to five years? Growth, new services or integration needs may rule some options out.
- What is the total cost over time? Compare the upfront build cost with ongoing licence fees, support and the cost of the problems you live with today.
If you are unsure, a short technical review is a sensible first step. An experienced developer can look at the code, the data and the way the system is used, then estimate the cost of each option, so the decision is based on evidence rather than guesswork.
Reducing the risk of change
Whichever route you choose, the safest projects avoid a single “switch-over weekend”. Instead, parts of the old system are replaced one at a time, data is migrated and checked in stages and the old and new systems sometimes run side by side for a short period. Good documentation of how the current system works, including all the unwritten rules staff follow, is invaluable.
Our legacy system modernisation service starts with an honest assessment of what you have, and sometimes the right recommendation is to leave it alone and just make it safer. If you would like a clear view of your options, get in touch.
