I want to share something that consistently shocks executives when I show them our IT budget breakdown: we spend approximately 70% of our technology budget just keeping existing systems running. Not improving them. Not building new capabilities. Just maintenance.
This isn’t unique to us. McKinsey research shows this is the norm across enterprises.
The 70-20-10 Framework
Most organizations follow some version of this allocation:
| Category |
Typical % |
Purpose |
| Run |
70% |
Keeping the lights on - operations, maintenance, core systems |
| Grow |
20% |
Incremental improvements to existing products/services |
| Transform |
10% |
High-risk/high-reward innovation and new business models |
But here’s what’s alarming: many legacy-heavy organizations see “Run” consuming well above 70%. In financial services, I’ve seen it reach 80-90%. Meanwhile, digital-native companies often operate at 60-25-15 or more aggressive innovation mixes.
Why This Matters
Every percentage point locked in legacy maintenance is a percentage point you can’t invest in:
- AI capabilities your competitors are building
- Cloud-native architectures that enable rapid scaling
- Developer experience that helps you retain talent
- New product features that drive growth
The Hidden Costs Beyond the Budget Line
The 70% figure actually understates the problem:
- Opportunity cost - features you couldn’t build because engineers were firefighting
- Talent attrition - engineers who leave for more modern stacks
- Security exposure - legacy systems are prime targets for attacks
- Compliance risk - auditors increasingly flag aging systems
- Integration tax - every new tool requires custom legacy connectors
Global legacy maintenance costs exceed $2.5 trillion annually. At Fortune 5000 companies, more than 70% of software in production is 20+ years old.
Breaking the Cycle: The ROI Case
Here’s the good news: modernization delivers measurable returns.
| Metric |
Expected Improvement |
| ROI over 3 years |
200-304% |
| Payback period |
6-18 months |
| Infrastructure cost reduction |
25-35% |
| Release cycle acceleration |
40-60% faster |
| Security breach risk reduction |
50% |
The math is straightforward: if you spend $10M annually on legacy maintenance and can reduce that by 25% through modernization, you’ve freed $2.5M per year for innovation - forever.
Where to Start
- Audit your actual allocation - Most organizations don’t know their true 70-20-10 split
- Identify the biggest maintenance drains - Usually 20% of systems consume 80% of maintenance budget
- Build the business case - Frame modernization as investment, not cost
- Start with quick wins - Target systems with highest maintenance cost and lowest migration complexity
- Measure and communicate progress - Make the shift from “Run” to “Transform” visible
The trap I see most organizations fall into: they treat legacy maintenance as a fixed cost. It’s not. It’s a choice that compounds over time.
What’s your organization’s Run/Grow/Transform split? How are you approaching the reallocation?
Sources: McKinsey IT Budget Research, Founder Nest Innovation Benchmarks 2026
Carlos, this is exactly the conversation I have with my board quarterly. The 70% figure is painful to hear, but I’ve learned to reframe it strategically.
From Cost Center to Investment Opportunity
The mindset shift that unlocks executive support: don’t present modernization as “reducing legacy costs.” Present it as “unlocking innovation capacity.”
When I pitch modernization initiatives, I never lead with “we’ll save $X on maintenance.” Instead:
“For every $1 we invest in modernization, we unlock $0.25 of annual capacity for innovation. That’s not a cost reduction - it’s a perpetual investment in our future competitiveness.”
The Strategic Reframe
| Legacy Framing |
Strategic Reframe |
| “Legacy costs are too high” |
“Our innovation capacity is constrained” |
| “We need to reduce maintenance” |
“We need to increase strategic agility” |
| “Old systems are a liability” |
“Modernization is an investment in velocity” |
| “Tech debt is out of control” |
“We’re building the foundation for AI and automation” |
What Actually Moves Boards
Three arguments that consistently get modernization budgets approved:
1. Competitive Velocity
“Our competitors ship features 3x faster because they’re not carrying our legacy burden. Every month we delay modernization is a month they extend their lead.”
2. Talent Arbitrage
“We’re paying 30% premium for engineers willing to work on legacy COBOL systems. Modernization lets us hire from a much larger talent pool at market rates.”
3. Risk Quantification
“Our legacy systems represent $X million in uninsured risk - security vulnerabilities, compliance gaps, and single points of failure. Modernization is risk mitigation with ROI.”
The Multi-Year Narrative
I present a 3-year trajectory:
- Year 1: Investment year - costs increase, lay foundation
- Year 2: Inflection point - maintenance costs start dropping, velocity improves
- Year 3: Payoff - significant capacity freed for innovation
The key is setting expectations that Year 1 will look expensive. If you promise immediate savings and don’t deliver, you lose credibility for future initiatives.
Carlos, how do you handle the CFO conversation about Year 1 investment?
Carlos, I want to add the engineering reality to this financial picture. In financial services, our “Run” percentage is closer to 85% - and the reasons are structural, not just technical.
The Financial Services Reality
At my organization, we have additional constraints that make the 70% problem even harder:
Regulatory Burden
- Every system change requires compliance review
- Legacy systems often have “grandfather” compliance status that we’d lose with modernization
- Audit requirements mean we can’t just “sunset” old systems - we need to prove data continuity
Integration Complexity
- Our core banking systems integrate with 200+ external partners
- Each integration is a contract - changing it requires negotiation, not just engineering
- Some partners are on even older systems than ours
Risk Tolerance
- When you’re processing billions in transactions, “move fast and break things” isn’t an option
- The cost of downtime exceeds the cost of maintaining parallel systems
- We’ve had modernization initiatives killed because the risk assessment showed potential for customer impact
How We Work Within These Constraints
Despite the challenges, we’ve found ways to chip away at the 85%:
1. API Wrappers First
Before modernizing core systems, we wrap them in modern APIs. This:
- Decouples new development from legacy constraints
- Creates a migration path for gradual replacement
- Gives teams modern interfaces even on old systems
2. Parallel Investment Tracks
We run two parallel budget conversations:
- Maintenance track: Keep current systems running (non-negotiable)
- Modernization track: Separate budget for strategic replacement
This prevents modernization from being raided when maintenance has emergencies.
3. Quick Win Accumulation
We identify small modernization opportunities that:
- Deliver measurable savings within 90 days
- Build credibility for larger initiatives
- Create internal advocates for modernization
Last year, three quick wins totaling $400K investment freed up $1.2M in annual maintenance - enough to fund the next round of modernization.
Carlos, do you see similar constraints in fintech, or is the regulatory burden lighter?
Carlos, I want to address the organizational dimension of breaking the maintenance cycle. At my EdTech company, we’ve found that team structure determines budget allocation more than any other factor.
The Team Structure Problem
When I joined, our engineering org was structured around systems:
- “Core Platform Team” (owned legacy systems)
- “New Initiatives Team” (built new features)
Result: 80% of engineering went to the Core Platform Team because that’s where all the fires were. New Initiatives was constantly understaffed.
The Reorg That Changed Everything
We restructured around outcomes, not systems:
Before: Teams owned systems
After: Teams owned product outcomes, including the systems needed to achieve them
What This Looked Like
Instead of:
- Team A: Maintains user management system
- Team B: Builds new user features
We moved to:
- Team A: Owns user acquisition and activation (uses AND improves user management)
- Team B: Owns user engagement and retention (uses AND improves core platform)
Why This Worked
When teams own outcomes, they have natural incentive to reduce maintenance burden:
- Self-interest alignment - Every hour spent firefighting is an hour not shipping features
- Decision authority - Teams can choose to invest in modernization when the ROI is clear to them
- Local optimization - Teams make pragmatic tradeoffs based on real context
- Visibility - Maintenance costs become visible at the team level, not hidden in shared buckets
The Budget Shift
Within 18 months of the reorg:
- “Run” dropped from 75% to 60%
- Release velocity increased 40%
- Engineer satisfaction (measured quarterly) improved significantly
The Catch
This only works if you give teams:
- Authority to make architectural decisions
- Budget autonomy (within guardrails)
- Metrics that incentivize long-term health, not just feature delivery
If you keep centralized control while distributing work, you get the worst of both worlds.
Carlos, how do you see the finance function partnering with distributed teams on these decisions?