Legacy systems do not announce their cost. They accumulate it. A government ministry running payroll on software written in the 1990s does not experience a single catastrophic failure. It experiences thousands of small ones: integrations that require custom adapters, features that cannot be built without touching systems no one fully understands, outages that take longer to diagnose because the engineers who built the original system retired a decade ago.
The cost is diffuse, incremental, and almost never attributed to its source. When a bank cannot launch a mobile product because its core banking system does not expose the APIs required, the cost appears in the budget as a delayed product launch, not as a legacy system liability. When a government agency cannot share data with another agency because their systems use incompatible formats, the cost appears as administrative overhead, not as technical debt.
This diffusion is precisely what makes legacy infrastructure so persistent. The cost is real but invisible. The investment required to address it is large and highly visible. The rational short-term decision for any individual budget holder is to defer the modernisation and absorb the drag. Repeated across thousands of institutions over decades, these individual rational decisions produce an irrational collective outcome: an economy running on infrastructure that constrains its own growth.
Legacy infrastructure compounds its cost through three mechanisms: integration friction, talent scarcity, and innovation ceiling.
Integration friction occurs when a modern system must interface with a legacy one. Every integration requires a translation layer between old and new data formats, protocols, and authentication models. These layers are expensive to build, fragile to maintain, and become more complex as the number of systems on each side grows. An economy with significant legacy infrastructure accumulates integration debt faster than it can address it, because each new modern system added to the ecosystem creates new integration requirements with every legacy system it must communicate with.
Talent scarcity follows from the long tail of legacy system maintenance. COBOL developers command premium rates not because COBOL is a valuable skill but because there are very few of them and many systems that depend on them. The same dynamic applies to engineers with deep knowledge of legacy enterprise platforms, end-of-life databases, and deprecated frameworks. This scarcity premium is a direct tax on the organisations that depend on these systems, and it grows over time as the talent pool shrinks through retirement.
The innovation ceiling is the most significant long-term cost. Modern software products are built on assumptions about the infrastructure beneath them: API availability, real-time data access, cloud-native deployment, and mobile-first interfaces. Legacy infrastructure does not support these assumptions. Organisations whose core systems cannot expose APIs cannot build API-driven products. Those whose databases cannot handle real-time queries cannot offer real-time features. The legacy system does not just cost money to maintain. It defines the ceiling on what the organisation can build.
Addressing legacy infrastructure is not a binary choice between replacement and continuation. The appropriate intervention depends on the specific characteristics of the system and the organisation that depends on it.
Systems that are stable, well-understood, and not required to integrate with modern infrastructure are frequently best left in place. The cost of migration can exceed the benefit when the system is not actively limiting business capability. These systems warrant ongoing maintenance investment and clear succession planning, but not replacement.
Systems that are limiting business capability but contain logic too complex to safely rewrite are candidates for the strangler fig pattern: wrapping the legacy system in a modern API layer that exposes its functionality to new systems without requiring its replacement. This approach captures the integration benefit without the migration risk. The legacy system continues to run; the organisation's ability to build on top of it improves immediately.
Systems that are actively failing, preventing regulatory compliance, or blocking strategic initiatives require replacement. Here the question is sequencing: which components to extract first, how to run old and new systems in parallel during migration, and how to manage the data migration without losing historical records or introducing inconsistencies. These migrations are expensive and high-risk, but the cost of continuation is higher.
The economic case for legacy modernisation is not primarily about technology. It is about removing the constraints that prevent institutions from building the products, services, and integrations that their customers need. Every percentage point of GDP growth that a country's digital infrastructure is capable of enabling but currently cannot support is a permanent loss, compounding at the rate of the growth it prevents.
