# Legacy Modernization Assessment: [Portfolio, domain or programme name]

> Assessment of a legacy application portfolio and the modernization plan
> that follows from it: inventory, assessment criteria (business value,
> technical health, risk), a disposition for each application using the
> 7 Rs (retire, retain, rehost, relocate, replatform, repurchase,
> refactor or re-architect), a strangler fig plan for incremental
> replacement, data migration, dependencies, a sequenced roadmap, costs
> and benefits, risks and governance. Based on the widely used 7 Rs
> migration strategies and the strangler fig pattern. Replace every
> `[bracketed]` value and every row marked *Example*; the examples follow
> an insurer modernizing its policy administration estate.

<!--
Guidance: How to use this template
- Inventory first (section 2), then agree criteria (section 3) before
  anyone proposes a disposition. Dispositions chosen before scoring tend
  to follow the loudest stakeholder.
- Score every application with the same criteria and the same people.
  Calibrate on two or three well-known applications before scoring the rest.
- Prefer incremental replacement (strangler fig, section 5) over a
  big-bang rewrite for anything business-critical. Say explicitly where
  you chose otherwise and why.
- The roadmap must respect dependencies (section 7). A sequence that
  migrates a consumer before its provider has an interface is not a plan.
- Revisit the assessment at each phase gate; dispositions are decisions
  for now, not forever.
-->

## Document control

<!-- Guidance: Record ownership and approval. A modernization assessment commits budget, so name the sponsor and the approving body. -->

| Field | Value |
|---|---|
| Document ID | [MOD-ASSESS-001] |
| Portfolio / programme | [Name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@enterprise-architect] |
| Sponsor | [@business-sponsor] |
| Contributors | [Application owners, platform, security, data, finance] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related | [Application inventory], [TCO analyses], [Target architecture], [ADRs] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business sponsor | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief architect | [@name] | [Decision] | YYYY-MM-DD |
| Head of operations | [@name] | [Decision] | YYYY-MM-DD |
| Finance | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to scope, scores or dispositions, not wording. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: inventory and criteria |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Scores calibrated in workshop; dispositions proposed |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by programme board |

## Contents

<!-- Guidance: Keep aligned with the numbered headings. -->

1. [Introduction](#1-introduction)
2. [Application portfolio inventory](#2-application-portfolio-inventory)
3. [Assessment criteria and scoring](#3-assessment-criteria-and-scoring)
4. [Disposition using the 7 Rs](#4-disposition-using-the-7-rs)
5. [Target state and strangler fig plan](#5-target-state-and-strangler-fig-plan)
6. [Data migration](#6-data-migration)
7. [Dependencies](#7-dependencies)
8. [Sequencing roadmap](#8-sequencing-roadmap)
9. [Costs and benefits](#9-costs-and-benefits)
10. [Risks](#10-risks)
11. [Governance](#11-governance)
12. [Appendices](#12-appendices)

## 1. Introduction

<!-- Guidance: Explain why modernization is being considered now, what is in scope, and what success looks like in measurable terms. -->

### 1.1 Purpose and drivers

[State the business and technical drivers.] *Example:* The policy
administration estate runs on a mainframe whose support contract ends in
36 months. Product launches take nine months because rules are hard-coded
in COBOL, and four of the six engineers who know the system will retire
within five years. The board wants new products launched in under three
months and run costs reduced by at least 25%.

### 1.2 Scope

In scope: [applications, environments, business units]. *Example:* 12
applications supporting motor and home insurance, including their batch
jobs, interfaces and reporting extracts.

Out of scope: [list]. *Example:* the claims platform (modernized in
2024) and the corporate finance ledger.

### 1.3 Success measures

| ID | Measure | Baseline | Target | By |
|---|---|---|---|---|
| SM-01 | *Example:* Time to launch a new product variant | 9 months | 3 months | YYYY-MM-DD |
| SM-02 | *Example:* Annual run cost of the estate | USD 6.4 m | USD 4.8 m | YYYY-MM-DD |
| SM-03 | *Example:* Applications on unsupported platforms | 7 | 0 | YYYY-MM-DD |
| [SM-nn] | [Measure] | [Baseline] | [Target] | YYYY-MM-DD |

## 2. Application portfolio inventory

<!-- Guidance: List every application in scope with facts, not opinions. Use the CMDB as a starting point but verify with owners; inventories are usually 20-30% wrong. Include shadow IT that the business depends on. -->

| App ID | Application | Business capability | Owner | Users | Technology stack | Hosting | Age (years) | Annual run cost (USD k) | Criticality |
|---|---|---|---|---|---|---|---|---|---|
| APP-01 | *Example:* Policy Admin Core | Issue and maintain policies | [@owner] | 900 internal | COBOL, CICS, DB2 | Mainframe | 28 | 2,900 | Tier 1 |
| APP-02 | *Example:* Rating Engine | Price quotes | [@owner] | 900 internal, 40 brokers | COBOL batch, rule tables | Mainframe | 22 | 800 | Tier 1 |
| APP-03 | *Example:* Broker Portal | Broker quotes and binds | [@owner] | 2,300 brokers | Java 8, JSP | On-premises VMs | 12 | 420 | Tier 1 |
| APP-04 | *Example:* Document Generator | Policy documents | [@owner] | System | Commercial product v9 (end of support) | On-premises | 15 | 260 | Tier 2 |
| APP-05 | *Example:* Agent Commissions | Calculate commissions | [@owner] | 30 finance staff | MS Access, Excel macros | File share | 10 | 40 | Tier 2 |
| APP-06 | *Example:* Legacy Reporting | Monthly regulatory extracts | [@owner] | 15 analysts | Reporting suite on DB2 | On-premises | 18 | 310 | Tier 2 |
| APP-07 | *Example:* Old Quote Archive | Read-only quote history | [@owner] | 5 users | Oracle 11g | On-premises | 16 | 90 | Tier 3 |
| [APP-nn] | [Name] | [Capability] | [@owner] | [Users] | [Stack] | [Hosting] | [Age] | [Cost] | [Tier] |

Data sources for the inventory: [CMDB export date, interviews, cost
reports, licence records].

## 3. Assessment criteria and scoring

<!-- Guidance: Define each criterion with a 1-5 scale anchored by observable evidence. Keep business value and technical health separate; their combination drives the disposition. Score in a workshop with application owners and architects. -->

### 3.1 Criteria

| Dimension | Criterion | 1 means | 5 means | Weight |
|---|---|---|---|---|
| Business value (BV) | Strategic fit | No role in future strategy | Core to differentiating capability | 0.40 |
| | Business criticality | Rarely used; outage tolerable | Revenue stops during outage | 0.35 |
| | Change demand | No change requested in years | Constant change requests | 0.25 |
| Technical health (TH) | Supportability | Vendor or platform unsupported | Current, supported stack | 0.30 |
| | Maintainability | Few people can change it safely | Well-tested, documented, modular | 0.30 |
| | Scalability and performance | Fails at current peak | Ample headroom | 0.20 |
| | Security posture | Known unfixable weaknesses | Meets current standards | 0.20 |
| Risk (RK) | Operational and compliance risk | Low exposure | High exposure, regulatory finding likely | Not weighted; used as a flag |

### 3.2 Composite scores

Each dimension score is a weighted average of its criteria:

$$
BV_a = \sum_{k} w_k \, b_{ak}, \qquad TH_a = \sum_{k} v_k \, h_{ak}
$$

where $b_{ak}$ and $h_{ak}$ are the 1-5 scores of application $a$ and the
weights in each dimension sum to 1.

*Example* for APP-01: strategic fit 5, criticality 5, change demand 4 gives
$BV = 0.40(5) + 0.35(5) + 0.25(4) = 4.75$; supportability 1,
maintainability 1, scalability 3, security 2 gives
$TH = 0.30(1) + 0.30(1) + 0.20(3) + 0.20(2) = 1.60$.

| App ID | BV | TH | Risk flag | Quadrant |
|---|---|---|---|---|
| APP-01 | *Example:* 4.75 | 1.60 | High | High value, poor health |
| APP-02 | 4.40 | 1.90 | High | High value, poor health |
| APP-03 | 4.10 | 2.80 | Medium | High value, fair health |
| APP-04 | 3.00 | 2.20 | High (end of support) | Medium value, poor health |
| APP-05 | 2.60 | 1.40 | Medium | Low value, poor health |
| APP-06 | 3.20 | 2.60 | Medium | Medium value, fair health |
| APP-07 | 1.30 | 2.00 | Low | Low value, poor health |
| [APP-nn] | [BV] | [TH] | [L/M/H] | [Quadrant] |

The quadrant gives a starting point: high value with poor health points
to replatform or refactor; low value with poor health points to retire or
repurchase; high value with good health points to retain; low value with
good health points to retain with minimal investment or consolidate.

## 4. Disposition using the 7 Rs

<!-- Guidance: Choose one disposition per application (or per component for large ones) and justify it with scores, constraints and cost. Note that the 7 Rs are a vocabulary; your organisation may use slightly different names. -->

### 4.1 Definitions

The definitions below are written for this template.

| Disposition | What it means here | Typical trigger |
|---|---|---|
| Retire | Switch the application off; archive what must be kept and move remaining users to another system | Low value, overlapping capability, few users |
| Retain | Keep the application as it is for now and revisit later | Recently upgraded, low risk, or blocked by a dependency |
| Rehost | Move the application unchanged to new infrastructure, such as cloud virtual machines ("lift and shift") | Data centre exit with a fixed date; little change demand |
| Relocate | Move a whole platform to another hosting location without changing machines or software, for example moving a virtualisation cluster to a provider-hosted equivalent | Large estates on a common hypervisor; speed over optimisation |
| Replatform | Move with targeted changes to use managed services, such as a managed database or container platform, without changing the core design | Platform end of support; modest effort available |
| Repurchase | Replace the application with a commercial or SaaS product and migrate the data | Non-differentiating capability with a mature market |
| Refactor or re-architect | Redesign and rebuild, often into services, to gain capabilities the current design cannot provide | High value, high change demand, poor health |

### 4.2 Disposition per application

| App ID | Application | Disposition | Rationale | Target | Effort (person-months) | Wave |
|---|---|---|---|---|---|---|
| APP-01 | *Example:* Policy Admin Core | Refactor / re-architect | Highest value, lowest health; product agility is the main driver | Policy services on container platform | 160 | 2-3 |
| APP-02 | *Example:* Rating Engine | Refactor / re-architect | Rules must be editable by product teams | Rules engine service | 48 | 2 |
| APP-03 | *Example:* Broker Portal | Replatform | Sound design; Java 8 and VMs unsupported | Java 21 on container platform | 14 | 1 |
| APP-04 | *Example:* Document Generator | Repurchase | Commodity capability; product at end of support | SaaS document composition | 10 | 1 |
| APP-05 | *Example:* Agent Commissions | Repurchase | Spreadsheet risk; standard commission software exists | Commission module of finance suite | 6 | 2 |
| APP-06 | *Example:* Legacy Reporting | Replatform | Extracts still needed; move to data platform | Data warehouse and BI tool | 12 | 3 |
| APP-07 | *Example:* Old Quote Archive | Retire | Five users; data retained in archive storage | Archive store with search | 2 | 1 |
| [APP-nn] | [Name] | [R] | [Why] | [Target] | [PM] | [Wave] |

Disposition summary: [counts per R]. *Example:* 1 retire, 0 retain,
0 rehost, 0 relocate, 2 replatform, 2 repurchase, 2 refactor.

## 5. Target state and strangler fig plan

<!-- Guidance: Describe the target architecture briefly and link the full design. For each application being refactored incrementally, show how traffic moves from old to new piece by piece and how you know each step is safe. -->

### 5.1 Target state summary

[Summarise the target architecture.] *Example:* Policy, rating and
document capabilities exposed as services on the container platform,
event-driven integration through the enterprise event broker, an
operational data store per service, and the data platform as the single
source for reporting.

### 5.2 Strangler fig approach

The strangler fig pattern replaces a legacy system gradually: a routing
facade sits in front of the old system, new functionality is built
alongside it, and routes are switched to the new implementation one
capability at a time until the old system can be removed. The diagram
shows the intermediate state where quoting has moved and policy changes
have not.

```mermaid
flowchart LR
    U["Brokers and staff"] --> F["Routing facade (API gateway)"]
    F -- "quote, rate" --> N1["New rating service"]
    F -- "issue, amend, renew" --> L["Legacy Policy Admin Core"]
    N1 --> EB["Event broker"]
    L --> CDC["Change data capture"]
    CDC --> EB
    EB --> N2["New policy service (shadow mode)"]
    EB --> DP["Data platform"]
```

| Step | Capability moved | Routing change | Safety check before switch | Rollback |
|---|---|---|---|---|
| S1 | *Example:* Put facade in front of all policy and quote calls | 100% to legacy | Latency overhead < 20 ms | Remove facade route |
| S2 | *Example:* New quotes for motor | 10%, 50%, 100% of motor quotes to rating service | Price parity with legacy on 50,000 replayed quotes, tolerance 0.5% | Route back to legacy |
| S3 | *Example:* Policy issue for new motor policies | New policies only; existing stay on legacy | Shadow mode for 4 weeks, 0 unexplained differences | Route back; replay events |
| S4 | *Example:* Mid-term amendments for migrated policies | Per-policy routing by migration flag | Reconciliation report clean for 2 cycles | Flag reset per policy |
| S5 | *Example:* Decommission legacy motor functions | Remove routes | No traffic for 60 days | Restore from archive (not expected) |
| [Sn] | [Capability] | [Change] | [Check] | [Rollback] |

## 6. Data migration

<!-- Guidance: Data is where modernization programmes fail. State the strategy per data set, how quality is assured, and how you prove nothing was lost. -->

| Data set | Source | Target | Volume | Strategy | Quality checks | Owner |
|---|---|---|---|---|---|---|
| *Example:* Active motor policies | DB2 `POLMAST` | Policy service store | 1.2 m records | Trickle migration per policy at renewal plus bulk for remainder | Record counts, premium totals, 1% field-level sample | [@data-owner] |
| *Example:* Quote history | Oracle 11g | Archive store | 38 m records | One-off bulk export | Checksums per file; random retrieval test | [@data-owner] |
| *Example:* Rating tables | Mainframe VSAM files | Rules engine | 2,400 tables | Convert and verify by replay | Parity on replayed quotes | [@product-owner] |
| [Data set] | [Source] | [Target] | [Volume] | [Big bang / trickle / dual write / CDC] | [Checks] | [@name] |

Principles: [list]. *Example:* source remains the system of record until
reconciliation passes; every migration run is repeatable and logged;
personal data is not copied to non-production without masking;
retention rules are applied during migration, not afterwards.

## 7. Dependencies

<!-- Guidance: Map technical and organisational dependencies. Note which way each dependency points and which interface must exist before a migration step can start. -->

The diagram shows the main runtime dependencies between applications in
scope; arrows point from consumer to provider.

```mermaid
flowchart TD
    APP03["APP-03 Broker Portal"] --> APP02["APP-02 Rating Engine"]
    APP03 --> APP01["APP-01 Policy Admin Core"]
    APP01 --> APP02
    APP01 --> APP04["APP-04 Document Generator"]
    APP05["APP-05 Agent Commissions"] --> APP01
    APP06["APP-06 Legacy Reporting"] --> APP01
```

| ID | Dependency | Type | Impact on sequencing |
|---|---|---|---|
| DEP-01 | *Example:* APP-03 calls APP-02 and APP-01 synchronously | Technical | Facade (S1) must precede any portal change |
| DEP-02 | *Example:* APP-06 reads DB2 tables directly | Technical | Reporting must move to data platform before DB2 tables change |
| DEP-03 | *Example:* Container platform ready for Tier 1 workloads | Platform | Blocks all refactor work |
| DEP-04 | *Example:* Mainframe contract end date | Commercial | Hard deadline for APP-01 and APP-02 exit |
| [DEP-nn] | [Dependency] | [Technical / Platform / Organisational / Commercial] | [Impact] |

## 8. Sequencing roadmap

<!-- Guidance: Group work into waves that deliver value early and reduce risk. Quick wins (retire, repurchase of commodity apps) usually go first; they free budget and prove the delivery model. -->

The roadmap below shows three waves and the platform foundation they
depend on.

```mermaid
gantt
    title Modernization roadmap
    dateFormat YYYY-MM-DD
    section Foundation
    Container platform and facade   :f1, 2027-01-04, 120d
    section Wave 1
    Retire APP-07                   :w1a, 2027-02-01, 60d
    Repurchase APP-04               :w1b, 2027-03-01, 150d
    Replatform APP-03               :w1c, after f1, 120d
    section Wave 2
    Refactor APP-02 rating          :w2a, after f1, 240d
    Repurchase APP-05               :w2b, 2027-07-01, 120d
    section Wave 3
    Refactor APP-01 policy          :w3a, after w2a, 420d
    Replatform APP-06 reporting     :w3b, after w2a, 180d
    Mainframe exit                  :milestone, m1, after w3a, 0d
```

| Wave | Content | Exit criteria | Value delivered |
|---|---|---|---|
| Foundation | *Example:* Platform, facade, event broker, CI/CD | Tier 1 readiness review passed | Enables all later waves |
| 1 | *Example:* APP-07, APP-04, APP-03 | Archive live; documents on SaaS; portal on platform | USD 0.5 m annual saving; two unsupported products removed |
| 2 | *Example:* APP-02, APP-05 | Motor and home quotes on new rating; commissions in finance suite | Product teams change rates without code |
| 3 | *Example:* APP-01, APP-06 | All policies migrated; mainframe off | Contract exit; target run cost reached |

## 9. Costs and benefits

<!-- Guidance: Give one-off and recurring costs per wave and the benefits you will measure. Link the detailed TCO or business case. Be explicit about double running costs during migration. -->

| Wave | One-off cost (USD k) | Double running (USD k) | Run cost of wave scope after (USD k per year) | Annual saving (USD k) |
|---|---|---|---|---|
| Foundation | *Example:* 1,200 | 0 | 300 | 0 |
| 1 | 900 | 150 | 330 | 490 |
| 2 | 1,600 | 400 | 520 | 320 |
| 3 | 3,800 | 1,100 | 3,650 | 790 |
| **Total** | **7,500** | **1,650** | | **1,600** |

Measured benefits: [link to success measures in 1.3]. *Example:* annual
run cost falls from USD 6.4 m to USD 4.8 m (saving 1.6 m, 25%), product
launch time falls to 3 months, and seven unsupported platforms are
removed. Simple payback on one-off and double running costs of USD 9.15 m
is about 5.7 years at full savings; strategic benefits (time to market,
key-person risk) are the main justification.

## 10. Risks

<!-- Guidance: List the programme-level risks; keep application-level risks in each project. -->

| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| R-01 | *Example:* Undocumented business rules in COBOL are missed | High | High | Rule mining tools, parity testing by replay, shadow mode | [@name] |
| R-02 | *Example:* Key legacy engineers leave before knowledge transfer | Medium | High | Retention agreements; pair them with new team from month 1 | [@name] |
| R-03 | *Example:* Double running lasts longer than planned | Medium | Medium | Per-wave exit criteria; budget contingency of 15% | [@name] |
| R-04 | *Example:* Mainframe exit date slips past contract end | Medium | High | Negotiate 12-month extension option now | [@name] |
| [R-nn] | [Risk] | [L/M/H] | [L/M/H] | [Mitigation] | [@name] |

## 11. Governance

<!-- Guidance: Define who decides, how progress is tracked and when the assessment is revisited. -->

| Forum | Members | Cadence | Decides |
|---|---|---|---|
| Programme board | *Example:* Sponsor, CIO, chief architect, finance | Monthly | Budget, wave gates, scope changes |
| Design authority | Chief architect, domain architects, security | Every two weeks | Target design, ADRs, exceptions |
| Wave stand-up | Wave leads, product owners | Weekly | Delivery issues, dependencies |

Phase gates: each wave passes a gate with evidence against its exit
criteria (section 8), updated costs (section 9) and a refreshed risk view
(section 10). The assessment scores in section 3 are refreshed yearly or
when a major driver changes.

## 12. Appendices

<!-- Guidance: Keep definitions and references here. -->

### 12.1 Glossary

| Term | Meaning |
|---|---|
| Disposition | The decision on what to do with an application |
| Strangler fig | Incremental replacement of a system behind a routing facade |
| Shadow mode | Running the new implementation on real inputs without using its outputs, to compare results |
| CDC | Change data capture: streaming changes from a database log |
| Double running | Period when old and new systems both incur cost |

### 12.2 References

| Reference | Use |
|---|---|
| Martin Fowler, "StranglerFigApplication" (martinfowler.com) | Origin of the strangler fig pattern |
| Cloud provider migration guidance on the 7 Rs (for example AWS Prescriptive Guidance) | Disposition vocabulary |
| [Internal TCO analysis] | Section 9 figures |

## Standard and licence note

Based on common industry practice for application portfolio assessment,
the 7 Rs migration strategies (an extension of Gartner's original "5 Rs"
popularised by cloud providers) and the strangler fig pattern described
by Martin Fowler. Definitions are written in original words for this
collection; examples and figures are illustrative. Template licence: MIT.