Infrastructure Flexibility in a Changing World: Lessons from Banking's COBOL Crisis

Businesses constantly seek the next efficiency boost, the next competitive edge. Today, that means adopting powerful Software as a Service (SaaS) platforms that promise rapid productivity gains. But rushing towards efficiency without considering long-term flexibility can inadvertently tie your hands for the future. It’s a lesson the banking industry learned the hard way, one which can act as a cautionary tale. 

In an era of high business uncertainty - both technical and macroeconomic - preserving flexibility is more valuable than before. 

‍

The Ghost of COBOL: A Lesson in Lingering Constraints

The banking industry saw a silver bullet in COBOL. Starting in the 1950s, this programming language revolutionised banking. Fast forward to 2025: major institutions like Lloyds Bank are still embarking on decade-long, multi-billion dollar projects to escape the systems they embraced generations ago. Why? Because the technology has become deeply embedded and outcompeted by new infrastructure, leaving behind massive dependencies.

This isn't ancient history. Recent data shows 95% of US ATM transactions still rely on COBOL. The programmers who understand these systems are retiring, leaving a critical knowledge gap. This "technical debt" has become a literal financial drain, with scarce COBOL experts commanding high contractor rates ($100-400 per hour),banks are trapped by yesterday's solutions. The convenience offered by today's SaaS solutions risks creating the same constraints for businesses down the line. 

‍

Understanding the Lock-In Cycle: From Convenience to Constraint

How does this happen? The path to infrastructure lock-in isn't purely technical; it's deeply rooted in common business practices and incentives:

• The Incentive Problem: Companies naturally reward short-term efficiency. Quarterly metrics often celebrate the immediate savings from adopting a new SaaS tool but rarely factor in the potential future costs of migrating away from it. Individual departments choose tools that solve their problems best, sometimes without prioritizing overall company flexibility. IT teams are praised for smooth rollouts, not necessarily for building easy exit ramps. This focus on the "now" means future-proofing often takes a backseat.
  
  • Strategic Shift: Reward managers for maintaining business capability flexibility, not just successful tool implementations. Include "system independence" metrics in performance reviews for digital transformation leaders.  

• The Procurement Blind Spot: Standard procurement excels at comparing features and upfront costs but often overlooks the strategic risks of lock-in. Why would you consider ditching what seems like the best solution, just as you are procuring it? Key factors like data export formats, the completeness of APIs (how well the system talks to other systems), contract terms for exit support, and the potential cost of a future migration receive far less scrutiny. When evaluating SaaS platforms, this oversight mirrors the decisions made decades ago regarding COBOL.
  
  • Procurement Reform: Develop a lock-in risk assessment for significant technology purchases. This should explicitly evaluate data portability, API robustness, exit clauses, potential migration costs, and what it would take to maintain core business logic independently.

• The Integration Dilemma: Connecting different SaaS tools is often where the real value lies – streamlining workflows and data sharing. However, every integration point can reduce your flexibility to swap out a component later. It creates a tension: more integration can mean more value now, but less adaptability later. Unlike the banks decades ago, businesses today can manage this tension proactively, though it requires investment.
  
  • Governance Solution: Consider an enterprise architecture review board mandated to assess integrations for reversibility and potential lock-in, balancing immediate value against long-term freedom. They should be incentivised to get things done, not simply point out the risks - but they must also ensure the decreased flexibility is adequately priced in. 

• The Ownership Question: The banks using COBOL discovered that their core business processes were inseparable from the technology. They technically own their data, but struggle to use it effectively without highly specialized (and scarce) talent. With SaaS, the challenge is slightly different: while your data might be technically portable, the business logic, custom workflows, integrations, and team knowledge built around the specific SaaS tool often aren't easily transferred. You own the data, but the operational capability becomes tied to the vendor.
  
  • Operational Defense: Maintain "shadow" process maps – documentation showing how your business functions independent of specific tools. This blueprint preserves crucial knowledge and aids rebuilding capability if a system change is needed.

‍

‍

Strategies for Sustainable SaaS Adoption: Building In Flexibility 

Avoiding lock-in doesn't mean avoiding SaaS. It means adopting it strategically, with an eye on future adaptability. Here’s how non-technical leaders can guide their organisations:

1. Align Incentives With Independence: Ensure performance metrics and budgets explicitly value and reward maintaining business flexibility alongside technology adoption. Treat adaptability as a feature worth investing in.
2. Plan Your Exit Before You Enter: Include clear transition assistance requirements in SaaS contracts (data migration support, knowledge transfer, extended API access). Periodically run "exit drills" for critical systems – test your ability to extract data and imagine operating without that specific tool.
3. Develop Data Governance Beyond Compliance: Expand data governance policies beyond just security and privacy. Focus on ensuring data remains usable and independent from any single platform.
4. Build Deliberate Integration Architecture: Encourage IT teams to design connections between systems (e.g., via a central exchange layer) that minimize direct, hardwired dependencies between different SaaS vendors.
5. Document Business Capabilities, Not Just Tools: Insist on maintaining up-to-date maps of what your business does and how it achieves its goals, separate from the specifics of which tool is used currently. This preserves vital institutional knowledge.
6. Make Conscious Tradeoffs: Not all lock-in is equally risky. Use a framework to decide where deeper integration is acceptable and where flexibility is paramount:
   
   • Core vs. Peripheral: Demand maximum flexibility for core, differentiating functions; accept more lock-in for generic, peripheral ones.
   • Competitive Advantage: Invest in flexibility where processes give you an edge; accept less for commodity functions.
   • Ecosystem Maturity: Deeper integration is less risky in stable, mature technology areas; prioritise flexibility in new, rapidly evolving ones.

‍

The Real Cost of Digital Transformation

Flexibility isn't free. Maintaining the ability to easily change platforms adds costs - in implementation time, in governance overhead, and sometimes in feature limitations.

The banks that are still struggling with COBOL in 2025 aren't victims of poor technology choices. They're victims of failing to properly value flexibility against immediate gains. In the relatively stable world of the late 20th century, this was a shrewd trade. In the increasingly volatile world of the 2020s, the balance is tipped. 

The calculation is simple: The cost of maintaining flexibility must be weighed against the probability-adjusted cost of a forced transition. For banks, that forced transition to COBOL alternatives has cost billions, far more than maintaining flexibility would have.

For your business, the right balance depends on how central each system is to your operations, how quickly your market changes, and your risk tolerance. But the lesson from banking's ongoing struggle is clear: What seems expensive insurance today can seem like a bargain when change becomes inevitable. As you look forward to the next few years, ask yourself how likely such a change becomes.

‍