- Most teams know the system. It runs the business, nobody fully understands it, and every change feels like defusing a bomb. The instinct is to throw it away and start clean. That instinct is usually wrong, and it is expensive.
Enterprises spend somewhere between 60 and 80% of their IT budget just keeping
old systems alive, which leaves almost nothing for the work that grows revenue.
Modernization is how you claw that budget back. The hard part is doing it
without taking the business offline for a year.
Why full rewrites keep failing
A from-scratch rewrite sounds clean on a whiteboard. In practice it asks you to
reproduce years of accumulated business logic, much of it undocumented, while
the old system keeps changing underneath you. The new build chases a moving
target, the cutover slips, and the two systems drift apart.
The numbers back this up. A phased, business-case-led program typically reaches
positive ROI in 12 to 14 months. A full rewrite often takes 36 to 48 months
before it pays for itself, and that assumes it ships at all. Many never reach
feature parity.
The goal is not new code. The goal is a system you can change safely. Those
are not the same thing, and confusing them is what sinks rewrites.
The 7 Rs: pick a path per system
There is no single "modernization." The useful move is to treat each workload
separately and choose a pathway for it. The industry shorthand is the "7 Rs,"
and in practice three of them carry most of the work:
Rehost. Move the application to the cloud as-is, no code changes. Fastest,
lowest risk, and often the first step to stop the bleeding on hosting costs.
Refactor. Keep the external behavior, restructure the internals so the
code runs well on a modern platform. The right call when your logic is solid
but the stack is dated.Replatform. Make targeted changes (swap a database, containerize) to get
cloud benefits without a full redesign.
The remaining Rs (repurchase, rearchitect, retire, retain) cover the edges:
buying a SaaS replacement, splitting a monolith into services, switching off
dead features, or deliberately leaving something alone. The discipline is
deciding per system instead of applying one verb to everything.
The strangler fig pattern in practice
When a system is too important to pause and too tangled to rewrite, the safest
route is to grow the replacement around it. The strangler fig pattern, named
after the vine that envelops a tree, does exactly that: you build new
functionality alongside the old system and route traffic to it piece by piece
until the legacy core can be retired.
It works because every step is small and reversible. You put a routing layer in
front of the old application, peel off one capability at a time into a modern
service, and send that slice of traffic to the new path. If something breaks,
you route back. The business never sees a big-bang cutover because there isn't
one.
Start where it hurts and shows
Pick a first slice that is both painful and visible, like a checkout flow or a
reporting screen users complain about. An early win that people actually feel
buys you the trust and budget to keep going.
Where AI actually helps in 2026
AI now accounts for roughly a third of modernization spend, and for once the
hype maps to something real. The bottleneck in any legacy project is
understanding: nobody knows what the code does. Large language models are good
at exactly that part.
A model can read tens of thousands of lines of code in under an hour and
summarize dependencies, surface dead paths, or translate an old language like
COBOL into modern Java or Python. Teams report cutting discovery and refactoring
timelines by up to 40%. Used well, AI compresses the slowest phase of the work.
Used badly, it generates plausible code nobody reviews. Treat AI output as a
draft from a fast junior engineer: helpful for mapping the terrain and a first
pass at refactors, never a substitute for tests and human review.
A phased plan that reaches ROI
A program that ships looks roughly like this:
Inventory and triage. List every system and score it on business value
and pain. Modernize the high-value, high-pain ones first.Stabilize the hosting. Rehost or replatform the worst offenders to stop
wasting money on idle and over-provisioned infrastructure. Our
startup FinOps playbook
covers where that spend usually hides.Strangle the core. Put a routing layer in front of the monolith and move
capabilities out one at a time, each behind tests.Retire as you go. Switch off legacy features the moment their replacement
carries the traffic. Code you delete is code you never maintain again.
Done this way, modernization is a series of small, fundable wins rather than one
terrifying leap. Each step pays for the next.
If you are sitting on a system that everyone is afraid to touch, that fear is
the real cost. Talk to us and we will help you map a phased path
that keeps the business running while the old code quietly gets replaced.
Top comments (0)