Application Modernization Roadmap: 12-Month Template With Waves
8 min read ยท 2026-10-25
An application modernization roadmap is a plan that says which legacy applications you will change, how you will change each one (retire, rehost, replatform, refactor, replace) and in what order. It turns a portfolio of aging systems into waves of work with owners, dates and a milestone for each wave. The template below covers 12 months in six phases, from inventory to the first systems switched off.
Most guides stop at listing modernization strategies. This one adds what you need to run the program: a simple scoring grid to pick a strategy per app, a filled-in wave plan, who owns what, the metrics that show progress and a one-slide summary for leadership. Adjust the durations to the size of your portfolio, but keep the order: assess before you migrate, and plan decommissioning from the start.
The roadmap at a glance
Goal: By month 12, the first two waves of applications run on the target platform, the old systems they replaced are switched off, and the next waves are planned and funded. Duration: 12 months
Inventory and business goals (Weeks 1-6)
Know what you own and why you are modernizing it.
- Agree on two or three business goals with the CIO and business leaders, such as faster releases, lower run costs or retiring an unsupported platform.
- Build an application inventory: owner, users, business process, technology stack, hosting, contracts and support end dates.
- Pull data from the CMDB, cloud bills and license records instead of relying only on interviews.
- Map dependencies between applications, databases and integrations, at least for the critical systems.
Milestone: A complete inventory of in-scope applications with an owner for each and a dependency map of the critical systems, reviewed by enterprise architecture.
Assessment and strategy per app (Weeks 5-10)
Choose a modernization strategy for each application based on business value and technical health.
- Score each application on business value, technical health, risk (security, support end dates) and cost to run.
- Assign a strategy: retire, retain, rehost, replatform, refactor or replace with a SaaS product.
- Estimate effort and the main risk for each one, in ranges rather than exact numbers.
- Review the results with application owners, who often know about problems the data does not show.
Milestone: Every in-scope application has a strategy, an effort range and a named owner, approved by the architecture review board.
Target architecture and foundations (Weeks 8-16)
Prepare the platform and standards that every migration will use.
- Define the target architecture: hosting, container platform, data stores, integration patterns and identity.
- Set up the landing zone or platform with networking, security controls, logging and monitoring.
- Create the CI/CD pipelines, environments and templates that teams will reuse.
- Write migration standards: testing approach, data migration steps, cutover runbook template and rollback rules.
Milestone: The target platform passes a security review and a pilot application is deployed through the standard pipeline.
Wave planning and pilot (Weeks 12-20)
Group applications into waves and prove the approach on a low-risk pilot.
- Group applications into waves by dependency, risk and team availability, with quick, low-risk ones first.
- Pick a pilot that is real but not critical, such as an internal reporting tool.
- Run the pilot end to end: migrate, test, cut over, monitor, and then switch off the old version.
- Update the runbook and estimates with what the pilot taught you.
Milestone: The pilot application runs in production on the target platform, its old version is off, and the wave plan for the year is approved.
Migration waves (Weeks 20-44)
Move applications wave by wave with a steady, repeatable process.
- Run each wave with the same steps: readiness check, migration, testing with business users, cutover and hypercare.
- For large monoliths, use the strangler fig pattern: move one function at a time behind a routing layer.
- Hold a go/no-go meeting before each cutover with the app owner, operations and the business.
- Track risks, blockers and scope changes in a shared log reviewed every week.
Milestone: Waves one and two are live on the target platform, each with business sign-off after hypercare.
Decommission and plan the next year (Weeks 40-52)
Capture the value by switching off old systems and set the next round.
- Archive data according to your retention rules, then shut down old servers, licenses and contracts.
- Measure results against the goals set in phase one.
- Rescore the remaining portfolio and plan the next waves.
- Share lessons learned with application teams and update the standards.
Milestone: The replaced systems are switched off with their contracts ended, and next year's wave plan is approved by the CIO.
How to choose a strategy for each application
You will not modernize every application the same way, and you should not try. A simple scoring grid keeps the choice consistent and gives you a reason to point to when someone asks why their system is not being rebuilt.
Score each application from 1 to 5 on business value and on technical health. High value and poor health usually means refactor or replace. Low value and poor health often means retire. High value and good health may mean retain or a light replatform. Treat this as a starting point and confirm it with the app owner.
- Retire: few users, a duplicate of another system or a process that no longer exists.
- Retain: works well, low risk, no business reason to change it now.
- Rehost: move as it is to new infrastructure, often to meet a data center exit date.
- Replatform: small changes to use managed services, such as a managed database.
- Refactor: change the code or architecture to gain speed, scale or easier releases.
- Replace: move to a SaaS product when the app does something many products already do.
Example: a mid-size insurer's first year
Picture an insurer with around 120 applications, a data center contract ending in 18 months and a policy administration system that takes weeks to change. Here is how the first year could look.
The order matters. Quick retirements free budget and show results early. The hard refactor starts only after the platform and the process have been proven.
- Q1, assess: inventory done, 20 apps marked for retirement, policy admin flagged for refactor. Owner: enterprise architect. Milestone: strategy per app approved.
- Q2, foundations and pilot: container platform and pipelines live, internal claims reporting tool migrated as the pilot. Owner: platform lead. Milestone: pilot live and old version off.
- Q3, wave one: 15 low-risk apps rehosted or replatformed, 10 retired. Owner: migration lead. Milestone: wave one signed off by the business.
- Q4, wave two and first strangler slice: broker portal replatformed, quote calculation moved out of policy admin into a new service. Owner: policy admin product owner. Milestone: first slice live, data center racks released.
Who owns what
Modernization crosses IT, the business and finance, so name owners for each decision. Without them, choices stall in meetings and waves slip.
Keep a RACI on one page and attach it to the roadmap. Revisit it when a wave starts, since owners change as applications move.
- CIO or IT director (sponsor): goals, funding, priority calls between business units.
- Modernization program lead: roadmap, wave plan, status reporting, risk log.
- Enterprise architect: target architecture, strategy per app, standards.
- Platform or cloud lead: landing zone, pipelines, security controls, operations.
- Application owners: effort estimates, testing, business sign-off at cutover.
- Security and compliance: reviews before each cutover and data retention rules.
- Finance or FinOps: run cost baseline, savings tracking, contract exits.
Metrics to track
Report outcomes, not just how many apps moved. A migrated application that still runs next to its old version has added cost, not removed it.
Set a baseline in phase one for each metric. Review them monthly with the program team and quarterly with the sponsor.
- Applications retired: count and the run costs and contracts ended with them.
- Applications on the target platform: by wave, against plan.
- Run cost per application: infrastructure, licenses and support, from bills and contracts.
- Release frequency and lead time: for refactored apps, from your CI/CD tool.
- Incidents after cutover: during hypercare, from the service desk.
- Systems past vendor support: count, which should fall each quarter.
Risks and dependencies
The biggest risks rarely sit in the code. They sit in data, people and hidden dependencies. Log them early and give each one an owner and a fallback.
Review the risk log in the weekly program meeting. Promote any risk that could move a wave date to the sponsor's monthly review.
- Undocumented integrations. Owner: enterprise architect. Fallback: monitor network traffic before cutover to find unknown callers.
- Data migration problems. Owner: data lead. Fallback: rehearse the migration at least twice with production-sized data.
- Business teams too busy to test. Owner: application owner. Fallback: book test windows in the wave plan and agree them with business leaders.
- Skills gaps on the new platform. Owner: platform lead. Fallback: pair internal staff with experienced engineers during the first waves.
- Old systems never switched off. Owner: program lead. Fallback: put the decommission date in the wave plan and track it like a cutover.
How to present it to leadership
Leadership wants to know three things: what the business gets, when, and what it costs in effort and risk. Build one slide with a timeline of four quarters across the top and the waves as bars beneath it. Under each wave, show the number of apps, the main business benefit and the milestone.
Add a small box for the top three risks with owners, and one line on decisions you need, such as freezing new features on an app during its migration. Keep the scoring grid and the full inventory in the appendix. Update the slide every month with progress against each wave.
Common mistakes to avoid
- Starting migrations before the inventory is complete leads to surprise dependencies, so finish the inventory and dependency map for critical systems first.
- Applying one strategy to every application wastes effort, so score each app and pick a strategy per app.
- Picking a critical system as the pilot puts the whole program at risk, so pilot on a real but low-risk application.
- Forgetting to switch off old systems keeps costs high, so put a decommission date in every wave and track it.
- Leaving business users out of testing causes failed cutovers, so book their test time in the wave plan.
- Reporting only the number of apps migrated hides whether goals are met, so report run cost, retirements and release speed against the baseline.
Frequently asked questions
What is an application modernization roadmap?
It is a plan that lists the applications you will modernize, the strategy for each and the order of the work. It groups applications into waves with owners, dates and milestones. It also ties the work to business goals such as lower costs or faster releases.
What are the main application modernization strategies?
Common strategies are retire, retain, rehost, replatform, refactor and replace. Cloud providers and analysts publish slightly different lists, often called the Rs. Pick one per application based on its business value and technical health.
How long does application modernization take?
It depends on the number of applications, their complexity and your team's capacity. A first wave can often go live within a year, while large portfolios take several years. Plan in waves and review the roadmap every quarter.
What is the strangler fig pattern?
It is a way to modernize a large application step by step. You put a routing layer in front of the old system and move one function at a time to a new service. Over time, the new services take over and the old system can be switched off.
Where should you start application modernization?
Start with an inventory and a short assessment, then retire what nobody needs. Run a pilot on a low-risk application to prove the platform and process. Move on to critical systems only after the pilot works.