Planning checklist
Legacy Modernization Risk Matrix
A decision matrix for comparing retain, rehost, replatform, refactor, rebuild and retire options by component.
Published by SpeedInno · Material review 15 August 2026
Quick checklist
Review these items first. Marking an item is not proof of readiness; retain the decision, evidence and accountable owner described in the detailed guidance below.
- Business criticalityRecord users, operating dependency, tolerated interruption and accountable owner.
- Technical conditionReview dependencies, change friction, testability, security exposure and skills availability.
- Data and integration riskMap authoritative data, batch or real-time exchanges, reconciliation and hidden coupling.
- Operational conditionReview deployment, observability, recovery, cost evidence and incident history.
- Retain or rehostUse when urgency is mainly infrastructure or lifecycle; do not claim it fixes application structure.
- Replatform or refactorChange runtime or internal structure while controlling compatibility and regression risk.
- Rebuild or replaceUse when target capability and ownership justify recreating behavior; inventory hidden requirements first.
- Incremental cutoverDefine coexistence, validation, data reconciliation, rollback and retirement criteria.
How to use this resource
- 1.Work through it with the people who own the workflow, data and release decision.
- 2.Attach evidence or a named open question to every material answer.
- 3.Separate confirmed facts, assumptions, risks and decisions that require approval.
- 4.Finish with an owner, next decision and review date, not a checked document only.
Use four decision states, not a misleading percentage score
Confirmed
Evidence exists and the accountable owner accepts it.
Assumption
A working belief is recorded with a validation action and date.
Risk
The uncertainty can materially change scope, safety, cost or release.
Not applicable
The rationale is explicit and has been reviewed; it is not simply unanswered.
Assess the current estate
Score components with evidence rather than assigning one strategy to the entire system.
Business criticality
Record users, operating dependency, tolerated interruption and accountable owner.
Questions to resolve
- What is the verified current state of business criticality, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Technical condition
Review dependencies, change friction, testability, security exposure and skills availability.
Questions to resolve
- What is the verified current state of technical condition, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Data and integration risk
Map authoritative data, batch or real-time exchanges, reconciliation and hidden coupling.
Questions to resolve
- What is the verified current state of data and integration risk, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Operational condition
Review deployment, observability, recovery, cost evidence and incident history.
Questions to resolve
- What is the verified current state of operational condition, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Compare treatment and sequence
Each treatment changes a different risk.
Retain or rehost
Use when urgency is mainly infrastructure or lifecycle; do not claim it fixes application structure.
Questions to resolve
- What is the verified current state of retain or rehost, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Replatform or refactor
Change runtime or internal structure while controlling compatibility and regression risk.
Questions to resolve
- What is the verified current state of replatform or refactor, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Rebuild or replace
Use when target capability and ownership justify recreating behavior; inventory hidden requirements first.
Questions to resolve
- What is the verified current state of rebuild or replace, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
Incremental cutover
Define coexistence, validation, data reconciliation, rollback and retirement criteria.
Questions to resolve
- What is the verified current state of incremental cutover, and which source supports it?
- What must be true at the next approval or release point, and what is explicitly outside the decision?
- Which exception, dependency or failure condition could invalidate the current answer?
- Who can approve the answer, who performs the work and who responds when it fails?
Evidence to retain
- A current-state artifact, observation or system record, not recollection alone.
- The selected decision, alternatives considered and the reason for the trade-off.
- An accountable owner, dependency owner and review or expiry date.
- Observable acceptance evidence and a recovery or escalation path where failure matters.
How to turn the checklist into an implementation decision
1. Establish the baseline
Record what exists, how it was observed and where evidence is incomplete. Keep reported behavior separate from reproduced behavior. This prevents the future design from treating assumptions or one person’s workaround as an approved requirement.
2. Define the target and boundary
Describe the capability or decision the next phase must enable, the users and records it covers, and the adjacent work it deliberately does not replace. A clear exclusion is useful only when its operational consequence and owner are understood.
3. Resolve the highest-consequence uncertainty
Prioritise questions that can change architecture, data purpose, security, migration, acceptance, commercial scope or launch readiness. Test or decide those before polishing lower-risk screens and convenience features.
4. Create traceable delivery evidence
Link each accepted requirement to its decision source, implementation boundary, test or review method and release owner. When the requirement changes, update the connected artifacts instead of leaving contradictory copies in documents, tickets and code.
Expected output
The matrix should produce a component-level target, evidence, dependency sequence and reversible cutover plan.
Related capability