Every enterprise has them.
The systems everybody depends on and nobody wants to touch. Written in a language few people still know. Running on infrastructure that is expensive to maintain. Holding business logic that exists nowhere else.
These systems are not failures. Most of them have run the business reliably for decades. But at some point, they start holding the business back.
That is when the modernization conversation begins.
Why Modernize at All?
Modernization should always start with a business reason, not a technology one. The good reasons usually look like this:
- Changes take months when the business needs them in weeks
- Skills to maintain the system are disappearing
- Running costs or license costs are growing
- Security or compliance risks are increasing
- The system cannot support new channels, data needs or AI use cases
"It is old" is not enough on its own. Plenty of old systems are perfectly fine.
The Options
There is no single way to modernize. In practice, I look at each application and ask which of these options fits best.
- Retain: leave it alone for now. Sometimes the right answer.
- Retire: switch off functionality nobody really needs. Often the cheapest win.
- Rehost: move to the cloud with minimal change. Fast, but does not fix underlying problems.
- Replatform: make targeted changes to use managed cloud services.
- Refactor: re-architect for agility, scale and maintainability. Most effort, most long-term benefit.
- Replace: move to a SaaS product or a new platform.
The art is in choosing the right option for each application, rather than applying one approach to everything.
Why Big-Bang Rewrites Fail
The most tempting plan is also the most dangerous: rebuild the whole system from scratch and switch over in one go.
It looks clean on paper. In reality, the old system keeps changing while the new one is being built, the scope grows, the business waits years for value, and the cutover becomes a high-stakes event with enormous risk.
Modernization is a journey of many small, safe steps, not one heroic leap.
The Strangler Fig Approach
The pattern I recommend most often is the strangler fig. Named after a plant that gradually grows around a tree, it works like this:
- Put a routing layer, often an API layer, in front of the legacy system.
- Build new functionality, or rebuild one piece of old functionality, as a new component.
- Route that slice of traffic to the new component.
- Repeat until the legacy system has nothing left to do, then switch it off.
The business gets value continuously, risk stays small, and you can stop or change direction at any point.
How to Prioritize
When there are dozens of applications to consider, I find a simple assessment helps:
- Business value: how important is this application to current and future strategy?
- Technical health: how hard and risky is it to change and run?
- Cost: what does it cost today, and what would modernization cost?
- Dependencies: what else breaks or improves if we change it?
High value with poor technical health is usually where to start.
Do Not Forget Data and People
Data migration is often the hardest and most underestimated part of modernization. Plan it early.
And remember the people. The engineers who know the legacy system are your most valuable asset in modernizing it. Involve them, respect their knowledge, and give them a path into the new world.
Final Thought
The goal of modernization is not to have new technology.
It is to give the business the ability to change quickly again, safely, one well-chosen step at a time.