Mainframe Migration Project Plan: Phases and Timeline

9 min read ยท 2026-11-01

A mainframe migration project plan moves your applications, batch jobs and data off the mainframe in controlled waves. It has six phases: discovery, strategy, wave planning, build and test, cutover, then decommissioning. Each phase ends on a milestone your steering committee can check. Plan the timeline backwards from the date your mainframe contract renews. Before the first wave goes live, agree on the rule that triggers a rollback.

This guide is for the people who present the plan and own it: PMOs, project managers, IT directors and the consultants who work with them. It covers the phases and their dependencies, the main risks and how to roll back, how to split the work into waves, and a governance model with a RACI and a RAID log. The durations below are starting assumptions, based on planning practice and one published case. Once your pilot wave is done, replace them with your own figures.

The roadmap at a glance

Goal: Retire the mainframe one workload at a time, without breaking service, and finish before the hardware or software contract renews. Duration: About 20 to 23 months

  1. Discovery and inventory (3 months)

    List everything that runs on the mainframe and everything that depends on it.

    • Catalogue applications, JCL jobs, CICS or IMS transactions and their owners.
    • Map data dependencies, including which programs write to which Db2 tables.
    • List every integration point with outside systems, file transfers and reports.
    • Collect hourly MIPS data over several months, so month end peaks and seasonal peaks show up.

    Milestone: Signed inventory with one owner per application and a dependency map.

  2. Strategy and business case (6 weeks)

    Decide what happens to each application and how the move will run.

    • Give each application one of the 6R options: rehost, replatform, refactor, repurchase, retire or retain.
    • Choose the approach: big bang, parallel run or phased.
    • Pick the target: private, public or hybrid cloud, and IaaS, PaaS or SaaS.
    • Build the cost baseline from today's software licences, hardware, storage, specialist staff, and disaster recovery and business continuity.

    Milestone: The steering committee approves the strategy, the target and the budget envelope.

  3. Wave planning and team setup (4 weeks)

    Turn the inventory into an ordered set of waves and put the team in place.

    • Start with less critical or read-only workloads.
    • Put the workloads that write to the same Db2 tables in the same wave.
    • Close COBOL and mainframe skill gaps with training or outside support.
    • Set up the RACI, the RAID log and the change control board.

    Milestone: Wave plan approved, with a date, scope and owner for each wave.

  4. Pilot wave build and test (6 months)

    Move the first application from start to finish and prove the method works.

    • Convert or rehost the code and data for the pilot workload.
    • Run functional, performance and batch window tests against the MIPS baseline.
    • Run the old and new systems in parallel and reconcile their outputs.
    • Rehearse the cutover and the rollback at least once.

    Milestone: Pilot live in production and meeting its agreed SLOs, with a proven rollback.

  5. Remaining waves (6 to 9 months in total)

    Repeat the method for each wave, using what you learned in the pilot.

    • Update the runbook and the estimates with the pilot's actual figures.
    • Freeze changes on each workload while it migrates.
    • Hold a go/no-go review before every cutover.
    • Train users and support teams before each wave goes live.

    Milestone: Every in scope workload runs on the target platform.

  6. Decommissioning and closure (2 months)

    Shut down the mainframe safely and close the programme.

    • Archive the data you must keep for compliance, and record where it is stored.
    • Switch off the remaining jobs, interfaces and licences.
    • Compare run costs and service levels with the baseline.
    • Hold a lessons learned review and hand over to operations.

    Milestone: Mainframe switched off before the contract renewal date.

Mainframe migration risks and the rollback plan

The same risks cause the most damage on most programmes: dependencies nobody mapped, batch windows that run long on the new platform, data that does not reconcile, and missing COBOL skills. Code conversion tools help, but they are not exact. In the TechTarget article "5 steps for mainframe migration", Ken Marr, CTO at FNTS, estimates that mainframe code tools achieve a conversion accuracy percentage in the low 90s. So every converted program still needs people who can read the original code and test the result. Plan for that work in every wave.

Write the rollback plan before the cutover plan. For every wave, record the points below.

Go/no-go criteria for cutover should be facts you can check, not opinions. Typical ones: parallel run outputs reconcile across a full month end, batch completes inside its window, SLOs hold under peak load, users are trained, the support rota is staffed, and the rollback rehearsal passed.

  • The point of no return, after which rolling back costs more than fixing forward.
  • The trigger that starts a rollback, for example a failed reconciliation or a missed SLO.
  • Who makes the call and how long they have to decide.
  • How data written on the new platform during the cutover window gets back to the mainframe.
  • How long a full rollback takes, measured during the rehearsal.

Mainframe migration timeline: how long each phase takes

The hardest limit on your calendar is not technical. It is the date your mainframe hardware or software contract renews. In the same TechTarget article, Marr notes that when an organization decides it's time to get off the mainframe, it might have a year to 18 months to do so before its on-premises hardware and software come up for contract renewal.

Compare that window with the plan above. The phases add up to about 20 to 23 months, so a mid-sized estate may not fit inside one renewal cycle. If the renewal date comes before your plan ends, put these three options in front of the steering committee.

One published case gives you a reference point. The AWS Partner Network blog post "Complete Mainframe to AWS Migration with Candid Partners" describes a 40-year-old mainframe with 28 business applications, 266 integration points and 1.6 TB of live data. The whole discovery and analysis phase took three months, and the first app reached the cloud after six months. Two low business value applications were not migrated. Use these figures to sanity check your own estimate, not as a promise. Your timeline depends on how many integrations you have, how much code you refactor instead of rehosting, and how long your parallel runs need to last.

  • Start discovery now, before the business case is final, so you don't lose the first phase waiting for approval.
  • Negotiate a short extension or a reduced capacity term for the workloads that will still be running.
  • Cut scope by moving more applications to retain or retire, instead of squeezing the test phases.

How to plan waves for a mainframe to cloud migration

Waves let you learn on low risk workloads before you touch the ones that run payroll or billing. The AWS Prescriptive Guidance page on planning a mainframe replatform with a shared Db2 database suggests starting with less critical workloads, such as non-core business transactions or batch jobs, and treating read-only workloads as early candidates. It also suggests grouping workloads that share Db2 tables for write or update operations, which keeps data intact and lowers the risk of data conflicts.

A simple scoring grid helps you put the waves in order. Score each application from 1 to 3 on the four criteria below, then start with the lowest totals.

Do not size waves on the number of programs alone. Size them on the capacity they use. The same AWS guidance recommends collecting hourly MIPS data for both online and batch transactions (CICS or IMS, and JCL jobs). You can collect it from SMF records or with the IBM Sub-Capacity Reporting Tool (SCRT), ideally over several months. The guidance also notes that many IBM pricing models for MIPS center around peak usage. If you know which wave removes which peak, you know when savings can start.

  • Business criticality: what happens if it is down for a day.
  • Data coupling: how many tables it writes to that other applications also use.
  • Integration count: how many systems send it data or read from it.
  • Code complexity: rehost only, light changes, or a full refactor.

Governance: RACI, RAID log and steering reviews

Mainframe programmes usually slip because decisions are slow, not because the code is hard. Set up governance before the pilot starts, and keep it light enough to run every week. A workable RACI for each wave looks like the list below.

Keep one RAID log (risks, assumptions, issues, dependencies) for the whole programme, with one owner and one due date per line. Record the phase durations as assumptions and update them after the pilot. Review the log every week with the wave leads and every month with the steering committee. Every change in scope, date or approach goes through change control, including "small" ones like adding a report to a wave. The monthly steering pack can be three slides: the roadmap with today's position, the five biggest open RAID items, and the decisions needed.

  • Programme sponsor: accountable for scope, budget and go/no-go.
  • PMO or programme manager: responsible for the plan, the RAID log and reporting.
  • Application owner: responsible for business tests and sign off.
  • Mainframe and target platform leads: responsible for the build, data moves and runbooks.
  • Security, risk and compliance: consulted on every cutover, informed of every change.

Change management and stakeholder communication

A mainframe often runs processes people have used for decades. Screens change, report formats change, and so do the times jobs finish. Give each wave a communication plan that tells users what changes, when, and who to call. Bring business owners into testing early, so their sign off means something.

Look after the mainframe team too. These people hold the knowledge the programme depends on. Give them clear roles on the target platform or in decommissioning, so their expertise stays until the last job is switched off.

Common mistakes to avoid

  • Starting the build before discovery is signed off lets hidden integrations break cutovers later. Close the inventory and dependency map first.
  • Measuring capacity over a single week misses month end and seasonal peaks. Collect hourly MIPS data over several months.
  • Splitting workloads that write to the same tables across waves forces two systems to share live data. Keep them in one wave.
  • Planning a cutover without a rehearsed rollback turns a bad night into an outage. Test the rollback in every wave.
  • Migrating everything by default spends effort on low value code. Mark candidates for retire or retain during strategy.
  • Ignoring the contract renewal date can mean paying for another term. Build the timeline back from that date.
  • Presenting estimates as commitments before the pilot leads to broken promises. Label them as assumptions until the pilot gives you real figures.

Frequently asked questions

How long does a mainframe migration take?

It depends on how many applications, integrations and data you have, and on how much code you refactor. As a starting assumption, the plan in this guide adds up to about 20 to 23 months for a mid-sized estate. In the Candid Partners case on the AWS Partner Network blog, the whole discovery and analysis phase took three months, and the first app reached the cloud after six months. Base your full timeline on your own pilot results and your contract renewal date.

What should a mainframe migration project plan include?

It should include an inventory with dependencies, a 6R decision for each application, a wave plan, a RACI and RAID log, test and parallel run plans, cutover and rollback criteria, and a decommissioning step. Each phase needs a milestone the steering committee can check.

Which approach is best: big bang, parallel or phased?

For most estates, a phased approach with parallel runs on critical workloads works best, because each wave lowers the risk for the next one. Big bang only fits small, loosely coupled estates, where a single cutover weekend is realistic and the rollback has been rehearsed.

How do you handle the COBOL skills gap?

Map the skills each wave needs during planning. Then combine training for in house staff with outside support for the busiest periods. Keep the mainframe experts involved until decommissioning. They can check converted code and explain behaviour nobody documented.

Generate this roadmap with AI