Choosing a modernization strategy

Modernization is not one thing. For each application you choose whether to keep it, improve it in place, move it, rewrite it or buy something to replace it, and each choice trades cost, risk and speed differently.

Why modernize at all

Most large organisations run core systems written in COBOL over several decades. The code usually works and the platform is reliable, so the pressure to change rarely comes from failure. It comes from speed of change (a simple product change takes months), integration (mobile apps and partners need real-time access), skills (fewer people understand the oldest code) and cost (licences and processor usage). Good modernization starts by naming which of these problems you are actually solving.

The five common strategies

Consultancies and cloud vendors use slightly different lists (sometimes called the "Rs"), but most include the same core choices of modernization strategy.

Strategy	What it means	Main benefit	Main risk
Retain	Keep the application as it is, maintain it normally	No project cost or disruption	Problems that prompted the review remain
Refactor	Improve the code structure in place without changing behaviour	Low risk, done in small steps	Slow; does not change the platform or language
Replatform (rehost)	Move the code with minimal change to another runtime, such as a COBOL runtime on Linux or cloud	Can reduce platform cost quickly	Same old code on a new platform; performance and batch behaviour can differ
Rewrite	Rebuild the function in a new language and architecture	Modern design, wider skills pool	Highest risk: hidden business rules get lost; long, expensive projects
Replace	Retire the application and adopt a package or SaaS product	Vendor maintains the software	Business must adapt to the package; data migration and customisation costs

Deciding application by application

A portfolio rarely gets one answer. Teams usually score each application on business value (how important and how often it changes) and technical health (code quality, documentation, test coverage, skills), then pick a strategy per application. Application discovery and analysis tools help here by showing how programs, copybooks, files and tables connect.

A common way to map applications to strategies

High value, good health

Retain and integrateExpose through APIsAdd tests and pipelines

High value, poor health

Refactor incrementallyStrangle piece by pieceRewrite selected parts

Low value, good health

Retain with minimal effortConsider replatform for cost

Low value, poor health

Replace with a packageRetire if unused

Why big-bang rewrites so often fail

Hidden rules: decades of fixes encode business rules nobody wrote down. A rewrite from specifications misses them.
Moving target: the old system keeps changing while the new one is built, so the gap never closes.
All-or-nothing cutover: one weekend switch of everything means one very large risk.
Value arrives late: the business sees no benefit for years, and funding is often cut before the end.

This is why most current guidance favours incremental approaches: deliver value in small slices, keep the old and new running side by side, and switch over one function at a time. The next lesson covers the main pattern for doing this.

Measuring progress

Agree measures before the work starts, so the programme can show results rather than activity.

Measure	What it tells you
Lead time for a change	Whether the code is actually easier to change
Percentage of traffic on new services	How far a strangler migration has progressed
Programs and lines of code retired	Whether old code is really being removed, not just duplicated
Processor consumption of the old application	Whether cost savings are real
Production incidents per release	Whether speed has come at the expense of stability
Automated test coverage of critical paths	Whether changes can be made safely