There's a number that should terrify every CTO in banking and insurance: 60 to 80 percent. That's the share of IT budgets that most financial institutions spend on maintaining legacy systems — not building new capabilities, not innovating, not responding to market shifts. Just keeping the lights on.
I've spent 12+ years building and modernizing enterprise software for organizations in finance, insurance, defense, and energy. I've seen core banking platforms running on COBOL that were written before the internet existed. I've seen insurance claims systems where a single change request takes 6 months and costs $200K. And I've seen what happens when organizations finally decide to modernize — both the successes and the spectacular failures.
This article is the guide I wish someone had given me when I started working on legacy modernization. It's written for the decision maker — the CTO, CIO, or VP of Engineering — who knows their systems need to change but isn't sure where to start, how much it will cost, or how to avoid the horror stories.
The Real Cost of Keeping Legacy Systems Alive
Let me be direct: the biggest cost of legacy systems is not maintenance. It's opportunity cost. Every dollar and every engineer-hour spent patching a 25-year-old system is a dollar and hour not spent on digital products that could open new revenue streams, improve customer experience, or give you a competitive edge.
The Visible Costs
- Maintenance contracts: Legacy vendors charge premium rates for support on end-of-life systems. I've seen mainframe support contracts that cost $2-5M per year for a single institution.
- Specialized talent: COBOL developers, RPG programmers, and mainframe specialists are retiring faster than they can be replaced. The ones still available command $150-250/hour.
- Integration overhead: Every new digital product you build needs to connect to legacy systems through brittle, custom-built integrations that break whenever anything changes.
- Compliance burden: Meeting new regulatory requirements (DORA, PSD3, Open Banking) on legacy architecture requires workarounds on top of workarounds.
The Hidden Costs
- Speed to market: A feature that takes a fintech 2 weeks to ship takes a legacy-bound bank 6-12 months. This is the gap that's killing incumbents.
- Talent attraction: Top engineers don't want to work on COBOL. You're competing for talent with a tech stack from 1985.
- Security exposure: Legacy systems often can't support modern security protocols, creating attack surfaces that grow wider every year.
- Data silos: Critical business data is trapped in systems that can't talk to each other, making it impossible to build a unified view of the customer.
Michele's Take
I tell every executive the same thing: the question is not whether you can afford to modernize. The question is whether you can afford not to. Every month you delay, fintechs and insurtechs are building the future your customers will eventually demand. The cost of modernization is fixed. The cost of inaction compounds.
The 5 Modernization Strategies (And When to Use Each)
There is no single right way to modernize. The right approach depends on the system's criticality, the quality of the existing codebase, and how much disruption you can tolerate. Here are the five patterns I've used across dozens of enterprise modernization projects.
1. Encapsulate (API Wrapper)
What it is: You keep the legacy system running but wrap it in modern APIs, allowing new applications to interact with it through clean interfaces instead of direct database access or file-based integrations.
Best for: Systems that work correctly but are difficult to integrate with. Core banking ledgers, policy administration systems, or claims engines that are stable but isolated.
Risk level: Low. You're not changing the core system — just creating a modern facade around it. This is often the first step in a longer modernization journey.
2. Rehost (Lift and Shift to Cloud)
What it is: You move the legacy system from on-premise hardware to cloud infrastructure without changing the application code. This reduces infrastructure costs and improves scalability.
Best for: Systems where the primary pain is hardware maintenance, data center costs, or disaster recovery. Not suitable if the application itself is the bottleneck.
Risk level: Low to medium. The application doesn't change, but you need to validate that it works correctly in a cloud environment — especially around network latency, storage performance, and security configurations.
3. Replatform (Modernize the Stack)
What it is: You migrate the application to a modern platform — for example, moving from an on-premise Oracle database to a cloud-native PostgreSQL, or from a monolithic J2EE application server to containerized microservices.
Best for: Systems where the business logic is sound but the underlying technology is creating bottlenecks. This gives you modern operational capabilities (auto-scaling, CI/CD, observability) without rewriting business logic.
Risk level: Medium. You're changing the runtime environment, which means thorough testing is essential. But you're preserving the core logic, which reduces the risk of introducing new bugs.
4. Refactor (The Strangler Fig Pattern)
What it is: You progressively replace parts of the legacy system with new, modern services. The old and new systems run in parallel, with traffic gradually shifting to the new services. Over time, the legacy system is "strangled" — its responsibilities are fully taken over by the new architecture.
Best for: Large, complex systems that are too risky to replace all at once. This is the approach I recommend for most core banking and insurance platforms — it delivers value incrementally while managing risk.
Risk level: Medium. Each individual migration is small and testable. The complexity lies in managing two systems in parallel and ensuring data consistency during the transition.
The Strangler Fig in Practice
I've led projects where we extracted one microservice at a time from a monolithic insurance platform — starting with the least critical module (document generation) to prove the pattern, then progressively moving to policy management and claims processing. Within 18 months, 60% of the system was running on modern architecture while the legacy core continued to handle the rest. Zero downtime. Zero data loss.
5. Replace (Full Rewrite)
What it is: You build a completely new system from scratch and migrate everything at once (or in a big-bang migration).
Best for: Small, isolated systems where the existing codebase is beyond salvaging and the business logic is well-documented. Also appropriate when moving to a commercial off-the-shelf (COTS) solution.
Risk level: High. Full rewrites are the most common source of modernization failures. They take longer than expected, cost more than budgeted, and often introduce regressions because undocumented business rules in the legacy code get lost in translation.
Warning
The full rewrite trap: I've seen more modernization projects fail because of big-bang rewrites than any other cause. The temptation to "start clean" is powerful, but the reality is that legacy systems contain decades of accumulated business logic — much of it undocumented. Rewriting means rediscovering all of it. My rule: only rewrite what you can afford to get wrong for 6 months.
A Decision Framework: Which Strategy for Which System?
Every legacy system in your portfolio is different. Here's the framework I use with clients to choose the right modernization approach for each one.
| Factor | Encapsulate | Rehost | Replatform | Refactor | Replace |
|---|---|---|---|---|---|
| Business logic is sound | ✓ | ✓ | ✓ | ✓ | — |
| Code is maintainable | ✓ | ✓ | Partial | — | — |
| Need modern UX/APIs | ✓ | — | — | ✓ | ✓ |
| Can tolerate downtime | — | Low | Medium | — | High |
| Budget range | $200K-500K | $100K-300K | $300K-800K | $500K-2M | $1M-5M+ |
| Timeline | 2-4 months | 1-3 months | 3-6 months | 6-18 months | 12-36 months |
The 7 Mistakes That Kill Modernization Projects
I've either witnessed or helped rescue projects that failed because of these mistakes. Every one of them is avoidable.
- Starting with the most critical system. Your core banking ledger or claims engine is not where you learn. Start with a lower-risk system to build confidence, processes, and institutional knowledge.
- Underestimating data migration. Data migration is typically 40-60% of the effort in a modernization project. It's boring, it's messy, and it's where projects die quietly.
- No rollback plan. Every modernization step should be reversible. If you can't roll back within hours, your plan isn't ready.
- Ignoring the people. Technical migration is the easy part. Getting 500 operations staff to adopt new workflows is the hard part. Budget at least 20% of project cost for change management and training.
- Choosing technology before understanding the problem. "We're moving to microservices" is not a strategy. Understanding which business capabilities need to change is the strategy. Technology is just the tool.
- No incremental value delivery. If your modernization project doesn't deliver measurable business value within the first 6 months, you'll lose executive sponsorship. Plan for quick wins.
- Treating it as an IT project. Legacy modernization is a business transformation. It needs business ownership, not just IT ownership. The CIO can champion it, but the CFO and business unit leaders need to be at the table.
Building the Business Case: How to Get Executive Buy-In
The biggest challenge in legacy modernization isn't technical — it's political. Here's how I help clients build a business case that gets approved.
Quantify the Cost of Doing Nothing
Calculate the total annual cost of maintaining the legacy system: license fees, support contracts, dedicated staff, integration maintenance, and the cost of delayed features. In my experience, this number is always larger than people expect — typically 2-3x what's in the "official" IT budget because hidden costs are spread across multiple departments.
Model the Revenue Impact
For every month that a new digital product is delayed because of legacy constraints, calculate the lost revenue opportunity. If a new mobile banking feature could generate $500K/month in additional engagement, and legacy constraints delay it by 8 months, that's $4M in lost opportunity.
Present a Phased Roadmap
Never present modernization as a single $10M project. Break it into phases with clear milestones and off-ramps. Phase 1 should be achievable in 3-6 months with a budget under $500K, delivering tangible results that justify the next phase.
Michele's Take
The most successful modernization pitch I've seen followed this structure: "We're spending $3.2M/year maintaining System X. For $400K, we can modernize Module A in 4 months, which will reduce maintenance costs by $600K/year and enable Feature Y that Sales has been asking for." That's a pitch that gets approved because it has a clear ROI and a short payback period.
The Role of AI in Legacy Modernization
Since 2024, AI has started playing a meaningful role in legacy modernization — not in the hype-driven way that vendors promise, but in specific, practical applications.
- Code comprehension: AI tools like Claude and GPT-4 can read and explain legacy COBOL or RPG code, helping modern developers understand business logic without needing legacy expertise.
- Automated test generation: AI can generate test suites from legacy code, creating a safety net before you start making changes.
- Documentation recovery: For systems where documentation is incomplete or nonexistent, AI can analyze code and database schemas to reconstruct business rules and data flows.
- Migration assistance: AI can translate code patterns from legacy languages to modern equivalents — not perfectly, but well enough to accelerate the process by 30-40%.
At Lasting Dynamics, we've integrated AI into our modernization workflow specifically for COBOL code comprehension and automated test generation. It doesn't replace the need for experienced architects, but it significantly reduces the time required for the discovery and analysis phase.
What Success Looks Like: A Realistic Timeline
Here's what a well-executed modernization journey looks like for a mid-size banking or insurance institution.
| Phase | Duration | Deliverable | Business Impact |
|---|---|---|---|
| Discovery & Assessment | 4-6 weeks | System inventory, dependency map, risk assessment | Clear picture of what you have and what needs to change |
| API Layer (Encapsulate) | 2-4 months | Modern APIs over legacy core | New digital products can be built without touching legacy code |
| First Module Migration | 3-6 months | One business domain on modern architecture | Proof that modernization works, team gains confidence |
| Progressive Migration | 12-24 months | Core systems incrementally moved | Maintenance costs drop 30-50%, speed-to-market improves 3-5x |
| Legacy Decommission | 3-6 months | Old systems turned off | Full cost savings realized, modern stack operational |
Total timeline: 18 to 36 months for a full transformation. But the key insight is that you start delivering value in month 3, not month 36. Every phase pays for itself.
The Bottom Line
Legacy system modernization is not a technology project. It's a strategic decision about whether your organization will compete in the next decade or slowly bleed out maintaining systems built in the last one.
The good news: you don't need to do it all at once. Start with assessment. Understand what you have, what it costs, and what's at stake. Then pick the right strategy for each system — encapsulate, rehost, replatform, refactor, or replace — and execute in phases that deliver measurable value every quarter.
The organizations that get this right don't just reduce costs. They transform from institutions that are constrained by their technology into organizations that are powered by it. And in an industry where fintechs and insurtechs are moving at startup speed, that transformation isn't optional anymore.
“The best time to start modernizing was five years ago. The second best time is this quarter.”
— Michele Cimmino