Legacy System Modernization: Replace, Rebuild or Extend

An old system is not automatically a problem

Software that has run your operation for fifteen years has fifteen years of business rules inside it. Some are written down. Many are not. That is the real risk in modernization: the code is replaceable, the knowledge is not.

So the first question is not how to replace it. It is whether it is hurting you, and where.

Signs it is time

• Only one or two people understand it, and one is near retirement.
• It cannot connect to the tools the rest of the business now uses.
• Simple changes take weeks and nobody is sure what they will break.
• The vendor has stopped supporting it, or the hardware it needs is hard to find.
• Staff keep spreadsheets beside it to do what it cannot.

One of these is a note for the file. Three is a plan.

The options, from least change to most

Cloud providers describe modernization as a set of strategies, often called the 7 Rs. In plain terms, for a business system, they come down to five choices.

Keep it. If it works, is supported and is not blocking anything, leave it. Doing nothing is a valid decision when you make it on purpose.

Extend it. Leave the core alone and build around it. A new web or mobile front end, or an integration layer that lets modern tools read and write its data. This is often the best first step, because it delivers something useful without touching the risky part.

Move it. Shift the same system onto modern infrastructure with few code changes. It solves hosting and hardware problems. It does not fix a design that no longer fits.

Rebuild it. Write a new system that does what the old one does, with the rules you still need and without the ones you do not. This costs the most and gives you the most.

Replace it. Buy a product that covers the same ground. Sensible when the work is standard and your process can bend to the product.

Why big-bang replacements fail

The tempting plan is to build the new system in full, then switch over one weekend. The trouble is that you learn everything at the end, when it is most expensive to be wrong.

Phased work is slower to describe and safer to do. Replace one area, run it alongside the old system, confirm the numbers match, then move to the next.

A vision care network with three clinics in two states moved to a new records and operations platform this way, over 18 weeks in three phases. Record lookup went from more than two minutes to under 15 seconds, and claims turnaround from seven to nine days down to two or three. Read the case study.

Data is the hard part

Most modernization projects that run late run late on data. Old systems hold duplicates, free-text fields used three different ways, and records that only make sense to one person.

Plan the data migration as its own piece of work. Test it with real records early, not in the last week.

What to ask before you start

1. What does it cost us to leave this as it is for another two years?
2. Which option solves that cost with the least change?
3. Can we deliver the first useful piece in under three months?
4. Who inside the business knows the rules, and is their time set aside?