Resource · Legacy Modernisation
The application modernization roadmap.
Four steps, each with its own artifacts and an exit gate. Score the portfolio, assign every application one of the 7 R's, ship one slice the strangler-fig way, and you walk into the funding meeting holding delivered work instead of a slide deck.
What is an application modernization roadmap?
An application modernization roadmap is a phased plan for moving a portfolio of legacy applications onto modern platforms, one slice at a time. It names every application, assigns each a disposition from the 7 R's, and sequences the work into funded phases with acceptance criteria and stop-points.
The version on this page is the one we build with clients: four gated steps from a blank sheet to a funded plan, about a quarter end to end, with a real piece of the migration shipped along the way as proof. The first slice is the credibility that gets the rest of the roadmap funded. (Leading the initiative as a new engineering leader is its own problem; that side lives in the First 90 Days playbook, which pairs with this page rather than repeating it.)
The vocabulary
What are the 7 R's of application modernization?
The 7 R's are retire, retain, rehost, relocate, replatform, repurchase, and refactor: AWS's extension of Gartner's original five R's, and the standard vocabulary for application dispositions. We use the industry framing rather than inventing our own because your cloud provider, your candidates, and half your board already speak it. Every application in the portfolio gets exactly one; the matrix of those decisions is the spine of the whole plan.
R1
Retire
Switch it off. Nothing to migrate.
The application has no active users, or its function moved elsewhere years ago and nobody turned it off. Check the access logs before you trust anyone's word on this.
R2
Retain
Leave it where it is. Revisit next cycle.
The application works, costs little to run, and touches nothing you are changing. Retain is a decision with a review date, not a euphemism for "too scary to look at."
R3
Rehost
Lift and shift to cloud infrastructure. No code changes.
You need to exit a data center on a deadline, or the application is stable and the win is purely operational. Fastest R, smallest payoff.
R4
Relocate
Move at the hypervisor level, VMware estate to cloud, without touching the workload.
Large virtualized estates on a hardware refresh or licensing cliff. Buys time; changes nothing about the application itself.
R5
Replatform
Small targeted changes to land on managed services.
The classic move: swap the self-managed database for RDS, the app server for a container platform. Most of the operational win of refactoring at a fraction of the cost.
R6
Repurchase
Replace it with a SaaS product.
The application does something a commercial product now does better: CRM, HR, ticketing, billing. The work is data migration and process change, not engineering.
R7
Refactor
Restructure the code itself for cloud-native operation.
Reserved for the applications that differentiate the business. Most expensive R by an order of magnitude. If you cannot say why this system earns it, it does not.
The method
How do you build the roadmap?
You build an application modernization roadmap in four steps: inventory and score the portfolio, assign each application one of the 7 R's, prove the migration pattern on a single slice, then scale the pattern into a funded phased plan. Each step produces named artifacts and ends at a gate: a condition that is either met or not. If a gate fails, the step is not done, whatever the calendar says.
Step 1
Typically 2 weeks
Inventory and score the portfolio
Know what you own, what it costs, and what depends on what.
- Build the full application inventory: name, owner, run cost, last meaningful change
- Map dependencies between applications, including the undocumented ones
- Score each application on business value and technical health, two axes, one chart
- Interview the people who run each system; they know what the documentation leaves out
Artifacts
- Application inventory with owners and run costs
- Dependency map
- Value-vs-health matrix
Exit gate
Every application has a named owner, a score, and a run-cost figure. No dispositions proposed yet.
Step 2
Typically 2 weeks
Assign dispositions and pick the first slice
Give every application one of the 7 R's. Choose the first piece of work.
- Work through the matrix and assign a disposition to every application
- Sequence the work by risk, value, and dependency order
- Pick a first slice that ships inside 60-75 days, has few dependencies, and is visible outside engineering
- Get leadership sign-off on the dispositions and the slice, in writing
Artifacts
- Disposition matrix
- Sequenced backlog
- First-slice scope with acceptance criteria
Exit gate
Leadership has signed the disposition matrix and funded the first slice.
Step 3
6-8 weeks
Prove the pattern on the first slice
Get one slice into production the same way the whole program will run.
- Build the new component alongside the old system, strangler-fig style
- Move traffic over gradually as the new path proves itself
- Document and test the rollback plan before cutover, not after
- Capture before-and-after metrics a non-engineer can read
Artifacts
- First slice serving production traffic
- Tested rollback plan
- Before-and-after metrics
Exit gate
The slice serves real production traffic and its before-and-after metrics are published internally. The old path shrinks from here; strangler fig retires it by disuse, and it does not need to be off on day one.
Step 4
1-2 weeks
Turn the pattern into the full roadmap
Scale what worked into a funded, phased plan.
- Write the full roadmap: phases with milestones, acceptance criteria, and per-phase pricing
- Build the risk register, each risk with a named owner
- State explicitly what you are not doing and why
- Present for funding with the first slice's results as the evidence
Artifacts
- Phased roadmap document
- Risk register with owners
- Funded next phase
Exit gate
The next phase is funded in writing. From here the roadmap runs the program.
The artifacts
What do the step 1-2 artifacts look like?
Two documents come out of the first two steps: the value-vs-health matrix that shows where the effort should go, and the disposition matrix that records what was decided and why. Here is the shape of both. The applications and scores below are invented for this example; the format is the real deliverable.
| Application | Disposition | Why |
|---|---|---|
| Billing engine | Refactor | The revenue path and the differentiator; also the deepest debt |
| Quote API | Replatform | Managed database and containers get 80% of the win cheaply |
| Customer portal | Retain | Healthy and valuable; review again in 12 months |
| Internal CRM | Repurchase | A commodity function; a SaaS product does it better |
| Batch ETL | Rehost | Stable but hardware-bound; lift it, revisit later |
| Legacy reporting | Retire | Access logs show three logins in the last quarter |
| Marketing site | Retain | Fine where it is; not worth any engineering attention |
One sentence of reasoning per application. If the reasoning does not fit in a sentence, the scoring conversation is not finished.
Receipts
Where this method comes from
The steps above are distilled from delivery work, not written for this page. Two of the engagements behind them, with the numbers:
$3,500/mo → $900/mo
Cloud run cost cut 74% and processing time taken from 30 hours to 10 minutes, the step-3 pattern of proving a slice with numbers a non-engineer can read.
Read the case study Global compliance advisoryExcel → platform in 4 months
Compliance operations rebuilt from spreadsheet workflows to a services platform now used across 20+ financial institutions, delivered slice by slice rather than as a big bang.
Read the case studyThe deliverable
What belongs in the roadmap document?
Seven sections. In our engagements, the roadmaps that skipped any of them got rewritten under pressure within a quarter, usually at the first funding conversation.
The disposition matrix
Every application, its assigned R, and one sentence of reasoning. This is the page executives actually read.
The sequence, with reasons
What moves first and why: risk, value, dependency order. A roadmap that hides its sequencing logic cannot survive its first re-plan.
Phases with acceptance criteria and stop-points
Each phase independently priced and acceptance-tested. At every phase boundary you can stop, redirect, or extend without losing the work already done.
The first slice's results
Real before-and-after numbers from step 3. The difference between a plan and a track record.
The risk register
Named risks, named owners, and the trigger that would activate each mitigation.
What you are not doing
The explicit exclusions. This list prevents more scope arguments than any governance process.
Metrics at 6, 12, and 24+ months
Run-cost reduction, deployment frequency, incident counts, extended to the far end of the program if it runs past two years. Chosen now so nobody can move the goalposts later.
Failure modes
How do modernization roadmaps fail?
- 01
Starting with architecture instead of the inventory
A target architecture chosen before the portfolio is scored is a preference, not a plan. The inventory decides where the effort goes. Do step 1 first.
- 02
Scoping a big-bang rewrite
A 12-18 month rewrite while the business keeps paying for the old system fails so often that Fowler's strangler fig essay exists specifically to warn against it. Refuse to scope one. The strangler-fig pattern survives contact with reality; the rewrite plan rarely does.
- 03
Marking everything "refactor"
Refactoring is the most expensive R and most portfolios need it for a handful of systems at most. When every application comes back marked refactor, the scores are describing the team's appetite rather than the portfolio.
- 04
Ignoring the people who run the legacy system
They kept it alive this long and they know what the documentation does not say. If they hear about the roadmap secondhand, expect your dependency map to be missing its most dangerous entries.
- 05
A roadmap without stop-points
Priorities change mid-program. A plan you can only follow or abandon will be abandoned. Phase boundaries with acceptance criteria let the roadmap bend without breaking.
Frequently asked
Questions we get
What are examples of application modernization strategies?
The strangler-fig pattern: build the new system alongside the old and move traffic over as components prove themselves. Lift-and-shift then optimize: rehost first for a deadline, replatform selectively afterwards. SaaS replacement: retire in-house builds of commodity functions like CRM or billing. And targeted refactoring: reserve full re-architecture for the systems that differentiate the business. A real program mixes all four; the disposition matrix says which applies where.
How long does application modernization take?
Expect the first production slice about a quarter in; the four steps above total roughly 11-14 weeks end to end. A full portfolio typically takes 12-36 months depending on size and how much lands in the refactor column. The honest answer for your estate comes out of the first two steps, not before them.
How is a modernization roadmap different from a cloud migration plan?
A migration plan moves applications; a modernization roadmap first decides which applications deserve to move at all. Retire, repurchase, and refactor are modernization decisions a pure migration plan never asks. If every application in your plan is marked rehost, you have a migration plan. Our cloud migration work covers the moving; this page covers the deciding.
Who should own the modernization roadmap?
One named senior engineering leader, with the authority to say no. Committees produce disposition matrices where everything is marked retain. If that leader is new in post, the people side of the initiative is covered in our First 90 Days playbook.
Should we extend the legacy system instead of modernizing it?
Sometimes, yes. If the system is due for retirement with the product it serves, the cheapest modernization is none. We talked through how to make that call on the Tack On or Rebuild episode: the short version is that bolting onto a system already past its value-vs-health line buys months and costs years. And the systems marked retain still need someone keeping them healthy; that is what our application maintenance and support service exists for.
When do you bring in outside help?
Most often for steps 1 and 2: the inventory, the scoring, and the disposition matrix benefit from senior eyes with no attachment to any system. That is exactly the scope of our Technical Assessment. If you are evaluating partners for the delivery phases, our guide to choosing a modernization partner is the checklist we would want used on us.
Want the first two steps done with senior eyes on them?
The Technical Assessment is steps 1 and 2 of this method run full-time instead of alongside the day job, which is how two typical-2-week steps compress into a one-to-two week engagement. You get the inventory, the value-vs-health matrix, the disposition matrix, and a first-slice scope with milestone pricing for the delivery phases. The funded roadmap still waits for the slice to ship, exactly as step 4 says. Fixed price agreed before we start, and you keep every artifact whoever does the delivery.