Mainframe Modernization Roadmap: 18-Month Plan in Seven Phases
9 min read ยท 2026-10-25
A mainframe modernization roadmap is a phased plan that shows which mainframe applications you will keep, move, rewrite or replace, in what order, and how you will keep the business running while you do it. It links each application to a strategy, a wave, an owner and a checkable milestone, from first inventory to switching off old workloads.
The template below covers the first 18 months in seven phases. That is long enough to finish discovery, prove one approach on a real workload and move the first waves to production. Large estates often take several years in total, so treat this as the first stretch of a longer program. It is written for CIOs, enterprise architects, mainframe and application leads, and the program managers who must keep the plan honest with the business.
The roadmap at a glance
Goal: A complete inventory, a strategy for every application, a proven pilot and the first two migration waves running in production, with a funded plan for the remaining estate. Duration: 18 months
Business case and goals (Weeks 1-6)
Agree why you are modernizing and what success looks like.
- Write the drivers with the business: cost, skills risk, speed of change, contract renewal dates or integration needs.
- Name the executive sponsor and form a steering committee with IT, finance, risk and business owners.
- Set three to five measurable goals, such as MIPS reduced, release frequency for key apps or batch window length.
- List hard dates that shape the plan, such as hardware or software contract renewals.
Milestone: Goals, sponsor and steering committee approved, with the key contract dates on the timeline.
Discovery and inventory (Weeks 4-16)
Know exactly what runs on the mainframe and how it connects.
- Inventory programs, copybooks, JCL, transactions, databases, files and batch schedules with code analysis tools.
- Map dependencies between applications, data stores and external interfaces.
- Measure resource usage per application, and note peak periods such as month-end or year-end.
- Find dead code and unused jobs, and confirm with owners which can be retired.
- Identify the people who know each application and record their knowledge.
Milestone: An application and data inventory with dependency maps, reviewed by application owners.
Strategy and target architecture (Weeks 12-22)
Pick a path for each application and design where it will land.
- Classify every application: retire, retain, rehost, replatform, refactor, rebuild or replace with a package.
- Design the target architecture, including data, integration, security and operations.
- Group applications into waves by dependencies, risk and business value.
- Estimate effort and capacity for each wave, and build the funding plan with finance.
Milestone: A strategy per application and a wave plan approved by the steering committee.
Foundations and pilot (Weeks 20-36)
Prove the approach on one real, low-risk workload.
- Set up the target environments, the CI/CD pipeline, monitoring and security controls.
- Pick a pilot application with few dependencies and a clear owner.
- Migrate it, then test functions, performance and data results against the mainframe output.
- Run it in parallel with the mainframe until the outputs match for an agreed period.
- Record lessons and update estimates for the waves.
Milestone: Pilot application live on the target platform, with matching outputs signed off by the business owner.
Wave 1 (Weeks 34-52)
Move the first group of applications with the process proven in the pilot.
- Migrate code and data for the wave and build any new interfaces back to the mainframe.
- Run regression and parallel tests with business testers.
- Plan cutovers outside peak batch periods, with a rollback plan for each.
- Switch off the migrated workloads on the mainframe once the parallel run passes.
Milestone: Wave 1 applications in production on the new platform and their mainframe jobs switched off.
Wave 2 and data (Weeks 48-72)
Move the next wave and the data it depends on.
- Migrate wave 2 applications and their databases or files.
- Set up data synchronization for data still shared with the mainframe.
- Replace mainframe interfaces with APIs or events where the target design calls for it.
- Track resource usage on the mainframe and confirm the reduction.
Milestone: Wave 2 live, shared data synchronized and the reduction in mainframe usage confirmed.
Skills, operations and next waves (Weeks 60-78)
Make the new platform run well and plan the rest of the estate.
- Train mainframe staff on the new stack and pair them with cloud or platform engineers.
- Move operations to the new monitoring, incident and change processes.
- Review progress against the goals and refresh the wave plan for the remaining applications.
- Agree the long-term role of the mainframe, if any, with the steering committee.
Milestone: Updated multi-year roadmap and funding approved, with operations owned by the run team.
Choosing a strategy per application
There is no single right way to modernize a mainframe. Most programs use several strategies at once, chosen per application. The decision depends on how much the business values the application, how often it changes, how good the code is and whether a package can do the job.
Make the choice visible on the roadmap. Color each application by strategy so leadership sees at a glance how much is being moved, rewritten or replaced, and where the risk sits.
- Retire: unused or duplicate applications. Switch them off after owner sign-off.
- Retain: stable systems that work and rarely change. Keep them and expose data through APIs.
- Rehost: move the code with few changes to a compatible runtime on new infrastructure.
- Replatform or refactor: convert code or data to a modern language or database, often with automated tools.
- Rebuild: rewrite in a modern stack, often piece by piece behind an API layer.
- Replace: switch to a package or SaaS product, such as a new core banking or ERP system.
Example: a filled-in roadmap for an insurer
Picture a mid-size insurer running policy, claims, billing and reporting on a mainframe, with a software contract renewal in 24 months. The goal is to reduce mainframe use before the renewal while keeping claims and billing stable.
Notice that claims stays on the mainframe in the first 18 months. The roadmap does not need to move everything, only the right things in the right order.
- Months 1-4 (enterprise architect): inventory of 4,200 programs and 1,100 batch jobs, 18 percent of jobs found unused and retired. Check: owner sign-off on the retirement list.
- Months 3-5 (CIO and steering committee): reporting rebuilt on a cloud data platform, billing refactored, claims retained with APIs, policy admin replaced by a package later. Check: wave plan approved.
- Months 5-9 (platform lead): pilot moves a premium calculation batch suite. Check: three month-end cycles with matching outputs.
- Months 9-13 (reporting lead): wave 1 moves regulatory and management reports. Check: old report jobs switched off.
- Months 12-18 (billing lead): wave 2 refactors billing with data sync to claims. Check: billing live and mainframe usage reduced for the renewal talks.
Who owns what
Mainframe programs fail when they are run as pure IT projects. Business owners must sign off what each application does today and confirm the new one does the same. Put their names on the roadmap next to each wave.
Also protect the people who know the old systems. Their knowledge is the scarcest resource in the program. Plan their time per wave and avoid letting the program depend on one person.
- Executive sponsor (CIO or COO): goals, funding and decisions across departments.
- Program manager: the roadmap, wave plans, risks, dependencies and status reporting.
- Enterprise architect: target architecture and strategy per application.
- Mainframe lead and subject matter experts: inventory, code knowledge and parallel run checks.
- Application owners in the business: acceptance of each migrated application.
- Platform and cloud engineers: target environments, pipelines and operations.
- Data lead: data migration, synchronization and reconciliation.
- Risk, security and audit: controls, access and sign-off for regulated workloads.
Risks and dependencies
Write each risk with an owner and a fallback, and review them at every steering committee. Mainframe risks are often hidden in batch schedules and shared files, so add new ones as discovery finds them.
The biggest dependency is time. Hardware and software contracts, regulatory deadlines and peak business periods all limit when you can cut over. Put them on the roadmap as fixed markers.
- Hidden dependencies: an unknown job reads a file you migrated. Owner: mainframe lead. Fallback: dependency scans before each wave and a longer parallel run.
- Knowledge loss: a key expert retires or leaves. Owner: program manager. Fallback: recorded walkthroughs and pairing from the start.
- Output differences: rounding, sort order or date handling changes results. Owner: data lead. Fallback: automated comparison of outputs during parallel runs.
- Performance: batch takes longer on the new platform. Owner: platform lead. Fallback: performance tests on full volumes before cutover.
- Contract timing: waves slip past a renewal date. Owner: sponsor. Fallback: negotiate a shorter renewal or capacity reduction early.
Metrics to track
Report progress in numbers the board and finance understand. Agree the definitions during discovery and record a baseline, so later reports compare like with like.
Avoid reporting only lines of code converted. It shows activity, not results. Lead with what was switched off and what the business gained.
- Applications by status: retired, migrated, in progress and remaining.
- Mainframe resource usage: MIPS or MSU consumption against the baseline.
- Batch jobs switched off: count per wave.
- Parallel run results: share of outputs matching, and the number of differences found and fixed.
- Change speed: release frequency or lead time for migrated applications.
- Incidents after cutover: number and severity in the first month of each wave.
How to present it to leadership
Use one slide with the waves on a timeline, each application colored by strategy and status. Add the contract dates as fixed markers. Below it, show three numbers: applications retired or migrated, mainframe usage against baseline and the next milestone date.
Leave out code statistics and tool names. Leaders care about risk, cost and the business result. If a wave slips, show the cause, the new date and its effect on the contract or the budget, plus the options you recommend.
Common mistakes to avoid
- Starting migration before the inventory is complete leads to broken jobs and surprise dependencies, so finish discovery and dependency mapping first.
- Applying one strategy to the whole estate wastes effort on stable systems, so choose a strategy per application.
- Picking a business-critical system as the pilot puts the whole program at risk, so pilot on a low-risk workload with a clear owner.
- Cutting over without a parallel run hides output differences, so compare outputs for at least one full business cycle.
- Leaving business owners out of testing means nobody accepts the result, so make them sign off each migrated application.
- Ignoring the mainframe team's knowledge slows every wave, so pair experts with new platform engineers from the first phase.
Frequently asked questions
What is a mainframe modernization roadmap?
It is a phased plan that lists each mainframe application, the chosen strategy for it, the wave it belongs to and its owner and milestones. It usually starts with discovery and a business case, then a pilot, then migration waves. It also tracks risks, contract dates and progress metrics.
How long does mainframe modernization take?
It depends on the size and complexity of the estate and the strategies chosen. A pilot and the first waves often take one to two years, and full programs for large estates can take several years. Plan in waves and refresh the roadmap after each one.
What are the main mainframe modernization strategies?
Common options are retire, retain, rehost, replatform, refactor, rebuild and replace with a package. Most programs mix several strategies. The right one depends on business value, how often the application changes and code quality.
Should you move everything off the mainframe?
Not always. Some organizations keep stable core systems on the mainframe and modernize around them with APIs and new data platforms. Decide per application, based on cost, risk and how much change the business needs.
How do you reduce risk in a mainframe migration?
Do a full inventory and dependency map, pilot on a low-risk application, and run old and new systems in parallel until outputs match. Plan cutovers outside peak periods with a rollback plan. Involve business owners in testing and sign-off.