Legacy systems are rarely bad systems. Many of them have run an organization’s most important work for decades, and they carry years of rules, exceptions, and hard-won knowledge. That’s exactly what makes them hard to replace.
Sooner or later, though, the cost of keeping them catches up: they can’t connect to newer systems, nobody can change them safely, the vendor stops supporting them, or the last person who understood them leaves. Then organizations face a choice that looks like all or nothing: keep living with the old system, or launch a large, expensive replacement project.
It doesn’t have to be either. Modernization works best one system at a time, and often one process at a time.
Three ways to modernize
Every organization’s systems are different, but most modernization follows one of three paths. Many projects use all three, in sequence.
1. Exchange data with the old system
Leave the legacy system in place, and build new services around it that read and write its data. Staff get a modern application, residents or customers get a portal, and the old system keeps doing the work it does reliably. This is often the fastest way to show results.
2. Integrate and replace step by step
Put a modern platform alongside the old system, and move its functions over one process at a time. Each process runs on the new platform as soon as it’s ready, while the rest still runs on the old system. The organization never stops, and every step proves itself before the next one begins.
3. Rebuild the system
When the old system has reached the end of its life, rebuild it on the new platform, designed around how the work is done today, not how it was done when the system was first written. Even then, replace one system at a time, not the whole landscape at once.
What we’ve learned
We’ve replaced legacy systems on Plant an App many times. These lessons come up every time.
Define the scope first. Are you replacing one monolithic application, or a set of applications tied together? Break a large project into parts that can be delivered on their own, such as HR in one part, a case management system in another.
Decide what you want from the new system. Some teams use the moment to rethink how the work is done. Others migrate first and improve later, knowing the new platform will keep changing with them. Either can be right. The mistake is not discussing it.
Watch the work, not just the documentation. Ask the people who use the legacy system to describe what they do, then sit with them while they do it. Much of the real work happens on autopilot, and the features people consider “so basic, of course it’s there” are the ones most often missed.
Expect the documentation to be wrong. On one project, six sprints in, we found that the documentation for a system we had to integrate with hadn’t been maintained, and the person who built it had left the year before. That system turned out to be small and near the end of its life, so we split the project in two: finish the main system as a first version, and rebuild the small one alongside it. Being able to build quickly turned a blocker into a decision.
Treat data migration as its own project. Migrating the records is the obvious part. The hidden part is the history behind them: who created each record, when, and what changed since.
Test against what users need. Testing isn’t only whether the application works, or whether it passes security and accessibility checks. It’s whether it does what the people using it need. Write the use cases down, with the expected outcome for each, and reserve time for the people who’ll test them, and for the people who’ll fix what they find.
Bring users on board before launch. A new system means a new way of working. Train people before it goes live, rather than waiting for their feedback after.
After the first system
The first replacement delivers a system. It also leaves behind a foundation: the data model, the integrations, the sign-in, and the team that knows how to build on them. The next system starts from there, which is why modernization gets faster with every step, instead of starting over each time.
Start with one critical problem. Expand wherever it creates value.