Chapter 32 Key Takeaways: Modernization Strategy

Threshold Concept

Modernization is not migration. The goal is making the system serve modern business needs — not moving it to a different platform. Organizations that equate modernization with "getting off the mainframe" are the ones that spend billions and fail. The right question is "what does the business need?" not "how do we replace the mainframe?"

The Four Rs

Strategy Definition Best For Danger Zone
Rehost Move to new platform, minimal code changes Simple batch, low z/OS dependency, dev/test environments CICS-dependent, high-throughput OLTP, five-nines requirements
Refactor Improve in place on z/OS (APIs, CI/CD, restructuring) Most applications — API exposure, dev modernization, knowledge transfer When used as "afraid to commit" — endless incremental without end-state
Replatform Move to new platform + architectural changes Moderate z/OS dependency, genuine long-term exit strategy When treated as "rehost plus wishful thinking" without budgeting for arch changes
Replace Build new, retire old Small (<100K LOC), clear requirements, obsolete business rules Core systems >500K LOC, "18-month rewrite" proposals, unclear requirements

Also: Retain (leave it alone — valid for working applications) and Retire (turn it off — highest ROI activity, typically 25-40% of portfolio).

The Portfolio Assessment

Score every application on three axes:

Business Criticality (1-5)     How important is it?
Technical Complexity (1-5)     How hard is it to change?
Technical Debt (1-5)           How much accumulated damage?

Quadrant guidance: - High criticality + high complexity = Handle with extreme care. Refactor or API-wrap. No big-bang. - High criticality + low complexity = Easy win for refactoring. - Low criticality + high complexity = Candidate for retirement or replacement. - Low criticality + low complexity = Retain or retire. Don't spend budget here.

Don't forget dependency mapping — you can't modernize an application that 347 other programs call without a plan for all 347 callers.

The Decision Framework

What does the business need?
  → Nothing → RETIRE
  → Exactly what it does today → RETAIN
  → Something different →
      Can the mainframe deliver it?
        → YES → REFACTOR
        → NO →
            Is the business logic worth preserving?
              → YES → REPLATFORM or STRANGLER FIG
              → NO → REPLACE (if < 100K LOC and clear requirements)

TCO Analysis — What Vendors Won't Tell You

Mainframe cost structure: Software licensing (45-60%) > Hardware (15-25%) > People (15-25%) > Facilities (5-10%) > Network (2-5%)

Hidden costs in cloud migration proposals: 1. Parallel running (mainframe stays on during migration) 2. Data migration and reconciliation 3. Performance tuning on new platform 4. Regression testing (25-30% of project effort) 5. Retraining staff 6. Third-party software re-licensing 7. Cloud egress charges 8. Incident response capability rebuild 9. Compliance re-certification 10. Opportunity cost (developers migrate instead of building features)

Kwame's rule: "If someone shows you a TCO comparison on one page, they're lying."

The Modernization Roadmap

Three Horizons

Horizon Timeframe Focus Success Metric
H1 0-12 months Quick wins: retire dead code, first APIs, modern tooling, knowledge capture Visible results that justify continued investment
H2 12-36 months Strategic: refactoring, IMS→DB2, strangler fig, AI-assisted documentation Measurable business value — faster delivery, API revenue
H3 36-60 months Optimization: hybrid architecture, long-term coexistence, workforce transition Stable modernized architecture, "project" becomes "operations"

Governance

  • Modernization Board (monthly): Progress review, phase approval, conflict resolution
  • Architecture Review Board (weekly during active modernization): Design consistency, no "shadow modernization"
  • Metrics Dashboard (weekly): MIPS trend, API count, cycle time, incident rate, budget vs. value

Sandra's most important rule

"No phase proceeds until the previous phase is stable in production for 30 days."

The Billion-Dollar Mistakes

Mistake Pattern Root Cause Lesson
"Figure out business rules later" Replace core system, discover missing rules after go-live The business rules ARE the code Requirements can't be fully extracted from large codebases
"Automated conversion saves us" Convert COBOL to Java mechanically Changes syntax, not architecture "COBOL in a Java costume" is worse than COBOL
"Cloud is always cheaper" Rehost without accounting for lost z/OS capabilities False TCO comparison Include ALL costs — parallel running, capability rebuilding, retraining
"We don't need mainframe people" Staff modernization team with cloud-only engineers Ignored domain knowledge Every team needs COBOL reader + cloud builder + business expert

Key Numbers

  • 38% of FBA's portfolio was dead code (consistent with industry: 25-40%)
  • $2.1M/year saved by retiring 1,200 dead batch jobs at FBA
  • 12,000 vs. 3,000 req/sec — COBOL vs. Java for SecureFirst's balance inquiry
  • 0.8ms vs. 14ms — p99 latency, COBOL vs. Java for the same service
  • 60-70% of rehost projects underestimate total cost by 2-3x (Gartner/Forrester)
  • $152.3M vs. $212M — FBA's 5-year TCO for Refactor vs. Replatform

Sandra Chen's Test

"Can you explain why we're doing this without using the word 'modern'?"

If the answer is no, it's not a strategy. It's fashion.