Legacy IT modernisation: a risk map for executives
How to think about replacing outdated systems without breaking the business processes that depend on them.
Almost every company that has been operating for more than ten years has its own "system that must not be touched". It might be an accounting module written in the nineties, a production management system on a platform that is no longer supported, or a CRM on a custom engine that only one person in the company understands. These systems work. They do something important. And everyone is afraid to touch them.
The problem is that "not touching" is also a decision, with its own risks. At some point the accumulated risks of keeping the system running outweigh the risks of changing it.
Why legacy is harder than it looks
A legacy system is not just old code. It is accumulated business logic that was often never fully documented. Rules, workarounds, exceptions to exceptions - all of it lives in the code and in the heads of a few people. When modernisation starts, the first discovery is almost always the same: what looked simple is more complex.
The second issue: legacy systems often act as the source of truth for other systems. Over years, integrations, exports, reports and manual processes have grown up around them. Replacing one component pulls on everything connected to it.
Four strategies and when to use each
Full replacement ("big bang") - complete development of a new solution with a single cutover. Highest risk: a long project, parallel support of two systems, high probability that the new solution will repeat the problems of the old one because the logic was never fully understood.
Use when: the system is small, the process is well-documented, and it is possible to pause operations during the transition.
Gradual replacement (strangler fig) - new features are written in the new system, the old one is retired gradually as functionality is migrated. A safer path for critical systems.
Use when: the system is large, continuous operation is required, and old and new parts can be clearly separated.
Wrapper approach (wrap and extend) - the old system stays, an API layer is built around it, new features are implemented on top. Often a temporary solution, but sometimes it becomes permanent.
Use when: the business risk of replacement is high, the core system is stable, and new integrations are needed without touching the core.
Cutting functionality - some legacy capabilities are no longer needed. Before migrating everything, it is worth asking: what do we actually still use?
What goes wrong in most projects
The main mistake: underestimating hidden complexity and overestimating speed. A project estimated at six months takes two years - because logic is discovered in the process that nobody knew existed.
The second mistake: focus on technology rather than business logic. The team concentrates on choosing a new framework and architecture, while the work of understanding and documenting the current logic goes undone.
The third mistake: no business owner. Legacy modernisation is not an IT project. It is a business project with an IT component. Without someone who understands the business processes and can make decisions about what to keep and what to change, the project inevitably stalls.
Questions before starting
- Have we fully documented the logic of the current system - including all exceptions and workarounds?
- Who is the business owner of the project and do they have authority to make decisions about business logic?
- What does the plan look like for the transition period - what happens to processes while two systems run in parallel?
- What is the success criterion - not "system is launched" but "business processes work correctly"?
- Is there a rollback plan, and under what conditions will we use it?
Legacy modernisation is an investment with deferred returns and high operational risk during execution. Managing that risk deliberately, rather than hoping things will go smoothly, is the only approach that works.