Legacy Modernization Assessment Template (7 Rs)
Portfolio inventory, value and health scoring, 7 Rs disposition, strangler fig plan, data migration, roadmap, costs and governance
Cara menggunakan: Use when planning the modernization of a legacy application portfolio. Build the inventory and agree scoring criteria before proposing dispositions. The main pitfall is a big-bang rewrite of critical systems; prefer incremental strangler fig steps with parity checks and respect dependencies in sequencing.
Pratinjau
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.
Document control
| 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
| 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
1. Introduction
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
| 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
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:
where and are the 1-5 scores of application and the weights in each dimension sum to 1.
Example for APP-01: strategic fit 5, criticality 5, change demand 4 gives ; supportability 1, maintainability 1, scalability 3, security 2 gives .
| 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
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
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.
| 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
| 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
The diagram shows the main runtime dependencies between applications in scope; arrows point from consumer to provider.
| 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
The roadmap below shows three waves and the platform foundation they depend on.
| 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
| 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
| 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
| 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
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.
Templat terkait
Software Architecture Document Template (4+1 Views)
SAD with Kruchten 4+1 views – goals and constraints, scenarios, logical, process, development, physical views, sizing, view mapping
Arsitektur & Desain SistemCloud Architecture Review Template (Six Pillars)
Well-architected style review across six pillars: questions, current state, high/medium/none risk, improvement plan, sign-off
Arsitektur & Desain SistemData Dictionary Template
Business and technical definitions per attribute: type, format, allowed values, source, owner, classification, code lists, derived fields