Modernization usually means rewriting everything wrong

There's a particular meeting I've been in more than once. Someone opens a slide deck, a system that's been quietly running payroll for twenty years gets labeled "legacy", and a room full of people who have never read a line of its code start nodding along to words like modernization, cloud-native, and digital transformation.

That's usually the moment the trouble starts.

The old systems still running are usually the good ones

The genuinely terrible old systems mostly died years ago. The ones still alive today are the opposite. They're stable, and they're full of edge-case handling that nobody ever bothered to write down. They survived because they worked, not because they were pretty and not because they used a fashionable framework.

A COBOL system that's moved millions of dollars without a bad night in fifteen years isn't bad software. It just has the wrong haircut.

The rewrite question is the wrong question

The first question in the room is almost always "how do we rewrite this?". That's already a wrong turn. The question worth asking is "what are we actually trying to fix?", and those are not the same thing.

Sometimes the real pain is missing documentation. Sometimes it's onboarding that takes six months, or a system with no API to integrate against, or reporting that can't answer a simple question. None of that requires touching the core business logic. But rewriting feels good, especially to a team that didn't build the original and doesn't carry any of its scars.

"Nobody understands the old system"

I hear this one constantly. "The old code is impossible to understand." And yet payroll still runs, invoices still go out, the warehouse still syncs, and customers still get billed the right amount. Somebody understood it well enough for the business to survive two decades.

The real problem usually isn't the code. It's that the people who knew it retired, the documentation was neglected, and maintenance got starved for years because nothing was ever visibly on fire. That's an organizational failure wearing a technical costume. Rewriting the software doesn't fix the culture that let the knowledge walk out the door.

Rewrites are very good at deleting invisible logic

This is where it gets expensive. Old enterprise systems accumulate thousands of small business rules over time: a special price for one customer, an accounting exception for one jurisdiction, a regulatory quirk, a workaround discovered during some incident in 2011. Most of it lives nowhere. Not in the docs, not in a ticket, not in a spec. It lives in the running system.

When a team rewrites from scratch, they tend to rediscover those rules one production outage at a time, with the customer watching.

"Modern" and "simpler" are not the same word

There's a specific move I've watched play out more than once. Replace one stable monolith with a dozen microservices, a service mesh, an event bus, distributed tracing, four cloud environments and a pile of YAML, all to reproduce a process that used to run on a single box in a basement.

You haven't simplified anything. You've turned a maintenance job into a permanent platform team.

The strangler pattern is boring for a reason

The modernizations that actually work tend to avoid the big-bang rewrite entirely. You wrap the stable system in an API, replace one piece at a time, keep the proven logic running while you go, and shrink the risk on every step instead of betting the company on a cutover weekend.

It doesn't make a thrilling conference talk. It just keeps the business alive. You don't demolish the whole building because one floor needs rewiring.

The hard part was never the technology

Most of these projects don't fail because COBOL is scary. They fail on unclear ownership, optimistic timelines, missing domain knowledge, and management treating a migration as a way to reset organizational problems through software. That almost never works.

The technology is usually the most cooperative thing in the room.

Greenfield is fun. Businesses don't live there.

I get the appeal. Greenfield work is clean architecture, new tools, and nobody else's old decisions to inherit. But real companies come with history, integrations, regulators, customer expectations, and twenty years of accumulated logic.

Software engineering isn't architecture cosplay. The job isn't to build the prettiest system. It's to keep the business running while you make it better.

Sometimes the right move is almost nothing

This one makes people uncomfortable. Occasionally the best modernization plan is to fix the backups, add real monitoring, write down how the thing actually works, put the source under version control, and upgrade the infrastructure carefully, without touching the core at all.

Not every old system needs reinventing. Some of them just need the maintenance they were denied for ten years.

Takeaway

There's a real difference between software that looks old and software that's failing. A surprising amount of "modernization" is aesthetic discomfort dressed up as technical necessity.

Old systems can genuinely become dangerous. Unsupported hardware, real security holes, vendor lock-in, nobody left to hire. Those are worth acting on. But a full rewrite is usually the most expensive possible answer to any of them.

The most senior decision you can make is to notice that the old system isn't the enemy. The missing understanding around it is.

I help teams maintain, debug, and modernize OpenVMS and other legacy systems without the risky rewrite: COBOL, RMS, Rdb, and integration with modern infrastructure. If you're sitting on something critical that everyone's afraid to touch, that's the conversation worth having.

• Openvms
• Legacy
• Modernization
• Architecture