There isn't one best way to modernize a mainframe.

The right approach depends on what's driving the effort, what the system does, how well it's understood, and how much disruption the mission can tolerate. Most successful programs end up using more than one approach, applied to different parts of the system.

That can feel like a non-answer, so this post breaks the options down in plain English, along with the questions that tend to point leaders toward the right one. (If you're looking for the basics on why these systems are still around, start with Is COBOL Still Used? What Government Leaders Should Know About Mainframe Systems.)

What are the main mainframe modernization approaches?

The names vary a little from one source to the next, but these are the options you'll hear most often:

Treat this as a general guide. Real systems rarely fit one box neatly.

How do you decide which approach is right for your system?

The Government Accountability Office (GAO) found in its 2025 review of critical legacy systems that agencies weigh the same four factors before deciding to modernize a legacy system: the risks of keeping it, how critical it is to the mission, the costs, and how well it performs today. Those are good starting points. A few more questions help narrow it down:

• What's really driving this? Cost, a hardware end-of-life date, a skills gap, security requirements, and a need for new capabilities each point somewhere different.
• How well is the system documented? If the business rules live mostly in the code and in a few people's heads, understanding the system must come before choosing a path.
• How much downtime can the mission tolerate? A payroll system and a back-office reporting tool call for different risk levels.
• Is this function unique to your agency, or is it a commodity? Custom mission logic is a reason to preserve it. A standard function may be better replaced.
• What's the funding horizon? Some approaches fit multi-year, staged funding better than a single large investment.

Why do big-bang rewrites so often struggle?

A full rewrite is sometimes the right answer. But when it's attempted all at once, the record isn't encouraging, and GAO's work shows why:

• The Department of Veterans Affairs made four efforts over two decades to modernize its health records system. According to GAO, the first three were abandoned over concerns about project planning, high costs, and the length of time to deliver capabilities.
• GAO found that FAA modernization investments for air traffic control systems can take an average of more than 12 years to complete. One contributing factor was that investments weren't always organized into manageable segments, even though federal policy requires it.
• The 1964-era Defense Department contract system we discussed in the first post was announced for retirement in 2002. It's still running.

The common thread is scale and sequencing. When everything must be replaced, tested, and cut over at once, one delay can stall the whole effort. GAO also noted more broadly that modernizations often take longer than expected, in part because of weak project management practices that cause schedule delays.

What does an incremental approach look like?

Rather than one cutover, an incremental approach moves functionality in stages. New capabilities are built alongside the legacy system, work shifts over piece by piece, and the old pieces are retired as they're replaced. You may hear this called the "strangler fig" pattern, after a tree that gradually grows around its host.

The benefits are practical. Each stage can be tested and funded on its own, the agency sees value earlier, and if something doesn't work, the problem is contained.

Treasury offers a federal example. For one of its tax processing systems, officials told GAO that the plan emphasizes delivering value as quickly as possible through an iterative, incremental approach, with a roadmap of releasable features planned in phases through 2026 and beyond. (GAO also noted that the plan still lacked some required elements, which is a reminder that incremental doesn't mean unplanned.)

Where do automation and AI fit in?

They're changing what's practical, especially for understanding and translating old code. The Defense Department team behind that 1964 system is running a proof of concept on automated tools that translate its COBOL code base into a modern language. Officials told GAO they believe critical stabilization work could be done in two to three years once funding is available.

AI can also help teams read, document, and map old code much faster than they could by hand. But speed isn't the same as correctness. Automated output still needs engineers to check it, and a rigorous comparison to prove the new system produces the same results as the old one. We cover that discipline in AI-Driven Legacy Modernization: The Discipline Behind the Orchestration.

What should you ask a modernization partner?

Whichever approach you lean toward, these questions help separate a real plan from a pitch:

1. How will you document what the system does before changing anything?
2. How will you prove the new system behaves like the old one?
3. How will the work be phased, and what do we get at each stage?
4. Who will handle the work, your own team or subcontractors?
5. How will knowledge be transferred to our staff?
6. What happens to the legacy system when the work is done?

That last one isn't an afterthought. GAO's baseline for a sound modernization plan includes milestones, a description of the work, and the planned disposition of the legacy system.

At The Canton Group, we've been modernizing legacy systems for government and enterprise clients since 1998, and our own in-house team does the work. We don't believe in a one-size-fits-all approach. Each system and mission is different, so the right path is tailored to the client's environment and needs.

Frequently Asked Questions

Not sure which path fits your system? Contact The Canton Group. We're happy to talk through your environment and your options.