## 1. Legacy System Assessment & Pain Point Mapping **System profile.** A 28-year-old life-insurance policy administration system on an IBM mainframe: about 4.5 million lines of COBOL, a DB2 database, nightly batch jobs for premium calculation, renewals and claims settlement, and CICS terminal access for 800 back-office staff. *[Stated directly]* | Label | Pain point (specific consequence) | Evidence | |---|---|---| | **PP1** | **Key-person concentration.** 2 of the 3 engineers who know the system best retire within 3 years, so the knowledge of how the system actually behaves leaves on a known clock. | *[Stated directly]* | | **PP2** | **Product launch latency.** Every new insurance product needs a 4–6 month development cycle; the target is 4–6 weeks. Likely root cause: product parameters and rules are embedded in COBOL logic rather than held as configuration. | Cycle time *[Stated directly]*; root cause *[Inferred from context]* — `<NEEDS-INPUT: rule-encoding-style>` | | **PP3** | **Undocumented business logic.** Documentation is scattered across 28 years and 4.5M lines, so the code itself is effectively the specification. Any change or migration must reverse-engineer intent from behavior. | Scattered documentation, size, age *[Stated directly]*; "code is the spec" *[Inferred from context]* — `<NEEDS-INPUT: documentation-inventory>` | | **PP4** | **High mainframe licensing and maintenance cost.** Management has stated this is secondary. | *[Stated directly]* — magnitude and contract structure `<NEEDS-INPUT: mainframe-cost-model>` | | **PP5** | **Two-sided skills gap.** The COBOL team has 6 people and is about to lose its two deepest experts. The 12-person Java/cloud team does not know the insurance domain. Neither team can carry the system alone. | Team sizes and domain gap *[Stated directly]*; consequence *[Inferred from context]* | | **PP6** | **Batch-and-terminal architecture.** Nightly batch plus CICS screens limits real-time and digital-channel capability. This was not raised as a complaint, so it is **not** a modernization target in this plan; it is listed because it shapes how PP2 can be solved. | *[Inferred from context]* | **Hard constraints carried into every later section** (not pain points, but they bound the solution): - **C1.** Policy data must be traceably retained for 30 years, and the migration must not break this. *[Stated directly]* - **C2.** Nightly premium-calculation and claims-settlement batches cannot be interrupted. The start-of-month renewal batch is the most sensitive period. *[Stated directly]* - **C3.** Unplanned downtime must not exceed 4 hours. Planned downtime is allowed only in an early-morning window on one Sunday per quarter. *[Stated directly]* — exact dates and duration `<NEEDS-INPUT: downtime-window-details>` - **C4.** Old and new systems must stay consistent during migration, and any calculation discrepancy is a compliance risk. *[Stated directly]* - **C5.** The budget is RMB 24M over 3 years, approved separately each year, and the board expects phased results in Year 1. *[Stated directly]* - **C6.** Validation of insurance rules can rely only on internal actuarial and underwriting experts, whose time is limited. *[Stated directly]* — capacity `<NEEDS-INPUT: actuarial-capacity>` ## 2. Modernization Goal Alignment Check | Goal | Linked pain points | What a new stack genuinely fixes | What it does **not** fix | |---|---|---|---| | **Primary: launch products in 4–6 weeks** | PP2, PP3 | Configuration-driven product definition, automated regression testing and CI/CD remove the COBOL development and regression-test portion of the cycle. *[Inferred from context]* | Actuarial pricing, underwriting rule design, sign-off and any regulatory filing do not shrink because the technology changed. How much of the 4–6 months is technology versus these steps is unknown. *[Inferred from context]* — `<NEEDS-INPUT: launch-time-breakdown>` | | **Primary: transfer key business rules before retirements** | PP1, PP3, PP5 | Nothing by itself. A technology migration that does not deliberately extract rules just moves the knowledge problem to a new language. Rule extraction is a **separate workstream that must start first**, because its deadline is the retirement dates, not the migration schedule. *[Inferred from context]* | PP3 is a domain-complexity problem. Insurance rules (reserves, riders, lapse/reinstatement, claims edge cases) stay complex in any language. | | **Secondary: reduce mainframe cost** | PP4 | Real savings arrive only when MIPS consumption and licenses actually fall, which requires moving workloads off the mainframe. That is unlikely to complete within a 3-year, RMB 24M horizon for 4.5M lines of COBOL. Near-term cost may **rise**, because replication, API traffic and dual running add mainframe CPU and cloud spend. *[Inferred from context]* | Cost reduction is not promised in this plan, consistent with management's statement that it is not the primary driver. `<NEEDS-INPUT: mainframe-cost-model>` | **Pain points modernization would not fix on its own:** - **PP3 (domain part).** The complexity lives in the insurance domain. Modernization can make rules explicit and testable but cannot simplify them. - **PP1 (timing).** Retirements are on a fixed clock. Only early, deliberate knowledge capture helps. A platform migration finishing in Year 3 would arrive too late. `<NEEDS-INPUT: retirement-dates-flexibility>` - **PP5 (domain gap).** New technology does not teach the Java/cloud team insurance. Only pairing and structured rule documentation do. - **PP6.** Intentionally left out of scope. ## 3. Migration Strategy Options **Full rewrite** A full rewrite is the only option that can remove deep architectural limits such as rules hardwired into a monolith, but it has the highest risk and longest timeline. Rebuilding 4.5M lines of rule-dense COBOL with unfamiliar domain staff, an RMB 24M budget approved year by year, and strict batch and consistency constraints makes an extended, high-stakes cutover close to unavoidable, and the rewrite would have to rediscover every undocumented rule (PP3) before it could replace anything. It fits PP2's architectural component in principle, but it does not fit C2, C4, C5 or the Year-1 expectation. *[Inferred from context]* **Strangler-fig incremental migration** Strangler-fig builds the new system alongside the old and moves capabilities over piece by piece behind a routing layer, keeping the legacy system operating throughout, but it takes longer overall and means paying to run two systems for an extended period. It matches C2–C4 well because the legacy batch keeps running while each capability is proven in shadow before taking real traffic. It can also address PP2 and PP3 directly, since each migrated capability forces its rules to be extracted and encoded as tests. Its cost is a long dual-running period that threatens the budget (C5) and requires discipline on integration and reconciliation. *[Inferred from context]* **Lift-and-shift** Lift-and-shift (re-hosting the COBOL/DB2 estate on non-mainframe infrastructure or an emulated environment) is the fastest, lowest-risk path for infrastructure-driven pain, but it does nothing for architectural or code-quality problems. It would address only PP4, and not necessarily even that once re-platforming cost, performance risk for a tightly scheduled batch estate, and regulatory hosting questions are counted. PP1, PP2, PP3 and PP5 would be untouched: the same 4.5M lines, the same undocumented rules, the same 4–6 month cycle. Given that cost is explicitly secondary, it addresses the wrong problem. *[Inferred from context]* — `<NEEDS-INPUT: regulatory-retention-rules>` **Encapsulation / API wrapping** Encapsulation leaves the legacy core intact and exposes modern interfaces to it, which is appropriate when the logic is valuable and stable but hard to integrate with, and it carries very low delivery risk. It does not shrink the codebase, does not capture knowledge (PP1, PP3, PP5) and does not reduce PP2 unless new products can be added without COBOL changes. It can also increase mainframe CPU consumption through added API traffic, working against PP4. It is valuable here as an enabling layer, not as the strategy. *[Inferred from context]* ## 4. Recommended Approach & Sequencing **Recommendation: a strangler-fig migration, using API encapsulation as its enabling layer, applied first to *new products* rather than to the in-force policy book.** A full rewrite is not recommended. The architectural component of PP2 is real, but C2–C5 rule out an extended high-risk cutover with this team and budget. Lift-and-shift is not recommended because it fixes only PP4, which management ranks last. *[Inferred from context]* **Honest scope statement.** Replacing 4.5M lines of COBOL and retiring the mainframe is not achievable within RMB 24M over 3 years with this team. This plan commits to delivering PP1 and PP2 relief and a *decision-ready* path on PP4, not to mainframe decommissioning. `<NEEDS-INPUT: mainframe-exit-expectation>` *[Inferred from context]* **First module to migrate: a product-configuration and premium-rating service for new products, run in shadow mode against the legacy premium calculation before it is ever authoritative.** Why this module: - It addresses PP2 directly, giving the highest pain-point relief per unit of effort. - It is read-only with respect to the legacy policy book (computes premiums, does not write policy state), so it does not touch C2. - Running it against the nightly legacy output forces rule extraction (PP3, PP1) as a by-product. - Failure costs nothing operationally: the business simply keeps using the 4–6 month COBOL path. *[Inferred from context]* The main risk is that rating is also the most compliance-sensitive logic (C4). That is why it runs in shadow, with 100% population comparison, before any authority is granted. | Phase | Timing | Scope | Addresses | Exit gate | Fallback if it goes wrong | |---|---|---|---|---|---| | **0. Rule discovery & safety net** | Months 1–6, continuing | Recorded knowledge-transfer sessions with the two retiring engineers (scheduled first); automated COBOL/JCL analysis; production-derived golden-master datasets of premium, renewal and claims inputs/outputs; actuary-validated rule catalog ranked by product and financial impact. Mixed squads pair COBOL engineers with Java/cloud engineers. | PP1, PP3, PP5 | Rule catalog covers the agreed top-priority products and calculations, with golden masters captured | No production change, so nothing to roll back. Rule capture continues regardless of later phases. | | **1. Enablement layer + shadow rating** | Months 4–12 | API wrapping of read-only legacy policy and customer services; log-based replication (CDC) from DB2 to a new operational store and immutable archive; reconciliation tooling; Product Factory rating service in shadow against the nightly batch | PP2, PP3, PP5 | Shadow rating shows zero unexplained differences across full-population comparisons over several consecutive nightly cycles, including one month-start renewal cycle | Switch API traffic back to direct CICS access via flag; disable CDC capture; turn shadow rating off. None of these affects legacy batch. | | **2. New products live on the new platform** | Months 13–24 | New products are issued and administered on the new platform as system of record, with its own minimal renewal and claims processing. Legacy batch is not modified. Pilot product first, then a second product to demonstrate the 4–6 week cycle. | PP2, PP5 | Pilot passes canary stages; second product launched within the 4–6 week target | Stop new-business intake on the new platform and route new sales to the legacy process. **Higher-risk phase:** policies already issued on the new platform cannot be un-issued, so canary caps and a simple pilot product limit exposure (see Section 6). | | **3. Decision gate** | Months 25–36 | Based on evidence, either migrate a low-complexity in-force cohort with dual-write, or extend the new-product model. Decide whether and when to plan mainframe exit. | PP4 | Funded only if Phase 2 hit its targets | Legacy remains authoritative for any migrated cohort until it has passed multiple clean cycles, including a renewal cycle; reverse sync available. | **Traceability.** Phase 0 → PP1, PP3, PP5. Phase 1 → PP2/PP3 (rating shadow) and the plumbing needed for everything after. Phase 2 → PP2. Phase 3 → PP4. PP6 is deliberately untouched. *[Inferred from context]* **Fit with team and budget.** - Each year's funded scope delivers standalone value (Year 1: rule catalog, test safety net, API/CDC layer, shadow-validated rating; Year 2: live new products), so a funding refusal in a later year does not strand the work. *[Inferred from context]* - Actuarial and underwriting time is spent on rule-catalog validation and on *adjudicating discrepancies*, while golden-master comparison does the bulk of verification. This is the main way to stay within C6. *[Inferred from context]* - External consultants are best used for COBOL analysis tooling, platform engineering and replication, not for validating insurance rules. *[Inferred from context]* — `<NEEDS-INPUT: annual-budget-split>` - **What the board sees in Year 1:** measurable rule-catalog coverage, golden-master parity, API layer in production, and shadow-rating parity results. The first *live* new-product launch is realistically Year 2. If product rules turn out to be table-driven in COBOL (`<NEEDS-INPUT: rule-encoding-style>`), an earlier pilot through the legacy path might become possible, but that must be confirmed before it is promised. *[Inferred from context]* ## 5. Data Migration & Integrity Strategy **Principle.** For the first two phases, DB2 remains the system of record for the in-force policy book. Data moves in three ways. *[Inferred from context]* 1. **Replication (Phases 1+).** Log-based CDC streams DB2 changes to a new operational store and an immutable archive. It is read-only toward the legacy system and sized to avoid pushing the nightly batch outside its window. `<NEEDS-INPUT: batch-window-headroom>` 2. **Born-new data (Phase 2).** New-product policies originate on the new platform, so no migration is needed for them. 3. **Cohort migration (Phase 3, only if the gate is passed).** In-force policies move in small cohorts with dual-write and reverse sync. **Continuous reconciliation (never a one-time check).** - After every nightly batch cycle, run a full-population comparison of record counts and checksums of key financial fields (premium, sum assured, cash value or reserve, claim amounts, policy status) between DB2 and the replica, alerting immediately on any mismatch. - Run intra-day sampling reconciliation (for example every 15 minutes) and monitor CDC lag continuously. - A mismatch blocks promotion to the next rollout stage until it is explained. - During any dual-write period, compare each transaction at write time in addition to the batch-level checks. **Calculation parity (C4).** - The new rating engine recomputes premiums for the full policy population in parallel with each nightly legacy run, compared to the smallest currency unit. The target is **zero unexplained differences**. - Every difference is classified as a new-engine defect, an undocumented legacy rule, or a legacy defect. For in-force policies the legacy result is the reference unless actuarial leadership formally records a decision otherwise, because those contracts were priced and issued under legacy behavior. *[Inferred from context]* **30-year traceability (C1).** - Every replicated or migrated record carries source system, source key, load timestamp and transformation version. - Archives are immutable, written in open and documented formats, and retain DB2 history and audit data. - Rules are versioned with effective dates, so that the premium for any historical policy can be reproduced as of its issue date. - Golden-master datasets and the rule catalog are retained as audit evidence. - No legacy data store or audit log is retired until its archive has been verified as queryable for the full retention period. `<NEEDS-INPUT: regulatory-retention-rules>` **Test-data handling.** Golden masters require production-derived data, subject to privacy and masking rules. `<NEEDS-INPUT: test-data-availability>` ## 6. Business Continuity & Cutover Plan **Continuity rules treated as hard requirements.** *[Stated directly: C2, C3]* - No change touches the legacy nightly batch, or its inputs, outputs or schedule, until proven in shadow. - Every cutover step is either executable live (flag or routing change, no downtime) or fits inside the quarterly Sunday window with a rehearsed rollback that completes inside that same window. If a rehearsal overruns, the step is deferred to the next window rather than extended. - Every rollback must be executable well inside the 4-hour unplanned-downtime limit. The working target is within 1 hour, including detection time. *[Inferred from context]* - **Renewal freeze.** No rollout stage begins, advances or changes from the last business day of a month until the month-start renewal batch has completed and been verified, plus a safety margin. `<NEEDS-INPUT: batch-window-headroom>` **Staged rollout for each capability** (applies to rating, then to new-product issuance): 1. **Shadow (0% authoritative).** The new system computes alongside legacy with no business effect. Advance only on sustained zero-unexplained-difference parity. 2. **Canary (about 1–5%).** A small cohort (for example one product, one channel or one team) uses the new system as authoritative, with caps on policy count and sum assured to limit exposure. 3. **Ramp (25%, then 50%).** Each step requires clean reconciliation across multiple nightly cycles, with no increase in incidents. 4. **Full for the scoped capability.** The legacy path stays warm and switchable until a full renewal cycle has passed cleanly. **Fallback if the new system underperforms.** Flip the routing flag to send traffic back to the legacy path while investigating. Cutover is never one-way for capabilities that can be reversed. Phase 2 is the exception: a policy already issued on the new platform cannot be un-issued, so caps, a simple pilot product and reconciliation guard against a bad batch of issuance, and this phase is explicitly flagged as the higher-risk one. *[Inferred from context]* **Use of the quarterly planned-downtime window.** Reserve it only for steps that touch the production mainframe region and cannot be done live. Each window is assigned a specific, rehearsed objective, for example enabling production API exposure in Year 1 and any mainframe-side routing hooks in Year 2. `<NEEDS-INPUT: downtime-window-details>` ## 7. Risk Register & Rollback Strategy | ID | Risk | Likelihood / impact | Mitigation | Rollback / fallback | |---|---|---|---|---| | **R1** | **Undocumented business-logic edge case**, discovered only when the new system handles it differently from legacy (PP3). | High / High | Full-population shadow comparison; golden masters built from real production history including rare cases; actuaries adjudicate each discrepancy; legacy remains the reference for in-force policies. | Stay on the legacy path; the rule is added to the catalog before the stage is retried. | | **R2** | **Premium or claims discrepancy** creating a compliance exposure (C4). | Medium / Very high | Zero-tolerance reconciliation; no authority granted until sustained parity; discrepancy log retained as audit evidence. | Flag back to legacy calculation; quarantine and correct affected records using the retained golden-master evidence. | | **R3** | **Performance regression** in the new stack under real production load, or CDC/API load disturbing the mainframe batch window. | Medium / High | Load testing against production-scale volumes; CDC and API traffic throttled and monitored; mainframe CPU headroom checked before each stage. `<NEEDS-INPUT: batch-window-headroom>` | Disable CDC or shed API traffic via flag; batch is unaffected by new-stack outages by design. | | **R4** | **Data migration or replication integrity failure.** | Medium / Very high | Continuous reconciliation (Section 5); cohort sizes kept small; legacy remains authoritative. | Re-sync from DB2; reverse sync for dual-write cohorts; halt next stage. | | **R5** | **Extended dual-running period** costs more than budgeted (C5). | High / Medium | Year-by-year scope that stands alone; stage gates tied to measured parity, not calendar dates; tracked running-cost forecast; Phase 3 funded only on evidence. `<NEEDS-INPUT: annual-budget-split>` | Pause at the end of any phase with the legacy path intact; Year-N deliverables stay useful. | | **R6** | **Key engineers leave earlier than expected, or knowledge capture is incomplete** (PP1). | Medium / High | Schedule retiring engineers' sessions first; record and transcribe them; seek retention or consulting arrangements. `<NEEDS-INPUT: retirement-dates-flexibility>` | Prioritize the highest-impact rules first so partial capture is still useful; slow Phase 2 scope if the rule catalog is not ready. | | **R7** | **Actuarial and underwriting capacity bottleneck** (C6). | High / High | Use golden-master automation for bulk verification; reserve expert time for adjudication and sign-off only; a fixed review cadence agreed up front. `<NEEDS-INPUT: actuarial-capacity>` | Reduce parallel product scope rather than lowering the verification bar. | | **R8** | **Incident during the month-start renewal period.** | Low / Very high | Renewal freeze (Section 6); no changes near the renewal batch. | Immediate flag rollback to legacy; legacy batch unaffected. | | **R9** | **30-year retention or traceability gap** (C1). | Low / Very high | Lineage fields, immutable archive, rule versioning with effective dates; retention rules confirmed with compliance before archive design is frozen. `<NEEDS-INPUT: regulatory-retention-rules>` | No legacy data store retired until its archive is verified; legacy stays intact. | | **R10** | **Mainframe cost rises rather than falls** from CDC and API load. | Medium / Medium | Measure MIPS impact in Phase 1; throttle; set expectations with management that PP4 is not a Year 1–2 outcome. `<NEEDS-INPUT: mainframe-cost-model>` | Reduce capture scope or frequency; fall back to batch-style extraction. | **Rollback summary by phase** (restating the Section 4 table): - **Phase 0:** nothing to roll back. - **Phase 1:** flags and capture switches; no legacy impact. - **Phase 2:** stop intake to the new platform; **issued policies cannot be un-issued** — this is the highest-risk phase and is gated by caps and canary stages. - **Phase 3:** reverse sync with legacy authoritative until cohorts have passed multiple clean cycles. ## 8. Open Questions & Data Requests 1. `<NEEDS-INPUT: rule-encoding-style>` How are product rules and parameters encoded today: table/parameter-driven, or hardcoded in COBOL logic? This determines whether any new product can reach production earlier through the legacy path. 2. `<NEEDS-INPUT: launch-time-breakdown>` What share of the current 4–6 month product cycle is COBOL development and testing versus actuarial pricing, underwriting sign-off and regulatory filing or approval? 3. `<NEEDS-INPUT: documentation-inventory>` What documentation actually exists (specifications, copybooks, JCL and scheduler definitions, test cases), and where is it? 4. `<NEEDS-INPUT: retirement-dates-flexibility>` What are the exact retirement dates of the two engineers, and could they stay on as part-time or contract knowledge holders? 5. `<NEEDS-INPUT: mainframe-cost-model>` What is the current annual mainframe cost, how is licensing structured (for example MIPS-based), and what are the contract end dates and exit terms? 6. `<NEEDS-INPUT: mainframe-exit-expectation>` Is management expecting mainframe decommissioning within or after the 3-year horizon, and what is the decision timeline? 7. `<NEEDS-INPUT: batch-window-headroom>` How long do the nightly and month-start renewal batches take relative to their windows, and how much mainframe CPU headroom exists for replication and API traffic? 8. `<NEEDS-INPUT: downtime-window-details>` What are the dates and duration of the quarterly Sunday planned-downtime windows, and can they be used for rehearsals? 9. `<NEEDS-INPUT: regulatory-retention-rules>` Which regulator's rules govern the 30-year retention, and what do they require on archive format, auditability, cloud hosting and data location? 10. `<NEEDS-INPUT: actuarial-capacity>` How many hours per month can actuarial and underwriting experts commit, and who can approve discrepancy decisions? 11. `<NEEDS-INPUT: annual-budget-split>` What is the budget ceiling for each year, does the RMB 24M include consulting and cloud running costs, and what evidence does the board need for each annual approval? 12. `<NEEDS-INPUT: test-data-availability>` Can production-derived inputs and outputs be used to build golden masters, and what privacy or masking rules apply?