Why legacy systems survive, and the consequences for the business

Almost every established enterprise has one: the core system that no one dares to turn off because it still supports a critical part of the business. It is rarely a secret. It sits on the list of systems that need modernization and has remained there for years without anyone taking decisive action.

The gap between consensus and action is one of the most expensive habits in enterprise IT. The legacy system continues to run the business, consume the budget, and dictate the pace for all teams that depend on it. Meanwhile, market demand points in the opposite direction: faster releases, deeper integration, and AI-ready data.

Legacy systems are rarely kept alive because anyone believes in them. They survive because defending an exit strategy is more difficult than maintaining the status quo.

Why the Legacy System Persists

The barriers primarily revolve around risk, capital, and institutional knowledge.

Asymmetrical risk. The system handles critical operations such as billing, policy administration, core banking, or ERP. A successful modernization goes unnoticed, while a failed one is remembered for years. Doing nothing feels safe, even when it is not.

A lack of precise understanding. Decades of business rules are embedded in the code, and the original authors have either left the organization or retired. Undocumented integrations and batch jobs mean that every modification carries unpredictable side effects.

Incompatible funding models. Budgets consistently favor highly visible new features over invisible risk reduction. The business case for modernization is often framed as "preventing a negative outcome," which is difficult to sell against growth initiatives.

Business ownership is required. Modernization demands a redesign of processes, ownership, and data. It requires as much business alignment as technological capability, yet it rarely receives the same level of attention.

Scarring from big-bang projects. Many enterprises carry the baggage of a failed system replacement program. Leadership remembers these failures and remains hesitant to attempt another major transition.

Contractual and skill lock-in. Licenses, support agreements, and long-term vendor commitments make exiting highly expensive. Furthermore, the individuals who understand the system best are often those whose roles depend on its preservation.

The Impact of Legacy Systems on Velocity and Agility

A legacy system often imposes a ceiling on how fast the entire organization can move, regardless of how agile the surrounding teams are. While the impact varies by system, the following challenges are most common.

• Changes are slow and high-risk. An legacy system typically has numerous dependencies. Even minor modifications require extensive testing because no one can confidently predict what they will impact. Consequently, the release cadence drops to quarterly or worse.

• Inelastic capacity. Many legacy platforms were engineered for a static load. When demand spikes, the typical solution is to over-provision the entire system because individual components cannot be scaled independently.

• Slow integration. Modern products, partners, and AI capabilities require APIs and data access that the system was never designed to provide. Teams build workarounds, which in turn introduce additional complexity.

• Locked data. AI and analytics require accessible, well-structured data. Legacy systems frequently store information in proprietary or obsolete formats, acting as a direct bottleneck to AI ambitions.

• Fear of change. Lead times expand, developers actively avoid high-risk areas, and technical debt continues to accumulate.

• Talent attrition. Top engineering talent prefers modern technology stacks, and the pool of specialists familiar with legacy infrastructure is rapidly shrinking.

• Compliance and security exposure. Unsupported platforms, difficult patching processes, and weak audit trails carry significantly more weight under frameworks like NIS2 and DORA than they did in the past.

• Innovation theater. Organizations build modern layers on top of legacy cores, but the legacy system still dictates what is possible. The resulting speed gains remain marginal.

Doing Nothing is Not the Safe Option

Leaving a legacy system untouched is a strategic decision in itself, and it carries two escalating risks.

Business continuity risk. The platform running the core business is often the most difficult to understand and recover. Vendor support expires, patching slows down, and the experts capable of fixing issues are becoming increasingly scarce. When a failure occurs, the outage disrupts billing, claims processing, payments, or production—and no one can guarantee recovery times or predict collateral system failures. DORA and NIS2 have elevated continuity and recovery to the executive board agenda.

Lost capacity for change. With each passing quarter the legacy system remains, the gap widens between business objectives and platform capabilities. New products stall waiting for release windows. Regulatory updates turn into major projects. AI initiatives fail due to inaccessible data. Competitors capable of executing changes in weeks set the market pace, leaving the organization in a reactive state rather than in control of its strategy.

Neither of these risks typically appears on a project plan. Consequently, the "do nothing" scenario repeatedly wins the budget debate: the cost of action is highly visible, while the cost of delay remains hidden.

The Real Blockers to Decommissioning

Most of the challenges and costs outlined above can be traced back to a single gap: the organization lacks visibility into how the legacy system is connected to the rest of the enterprise.

This blind spot determines whether a decommissioning project can be scoped, funded, and phased effectively. When dependencies are only partially documented, every estimate is a guess, and every guess favors postponing action.

This is why strangler fig patterns and modernization roadmaps look compelling in presentations but stall in execution. The plan assumes a map that does not exist. Without it, "decommissioning the system" remains a wish, and the legacy core remains in place.

Integrations are where this gap hurts most. Over the years, the system has accumulated point-to-point connections, file transfers, batch jobs, and reports feeding other applications—often built by former employees. Individually, these integrations are minor, but collectively they dictate what can be migrated and in what order. A practical entry point is to focus on connectivity rather than code: document what enters and exits the system, identify who depends on it, and determine the criticality of each flow. This focused list usually reveals where the exit strategy can safely begin.

A recent case in point. Bloomberg reported in September that Zeiss restructured its SAP cloud migration after costs escalated to over 200 million euros over several years. The original strategy was a greenfield build from scratch. This has now been abandoned in favor of converting existing systems.

The takeaway is not the failure itself, but that Zeiss committed early and still ended up here. In my experience, the tools are rarely the issue. The real challenge is establishing a shared understanding of what needs to change and having the organizational courage to shift the operating model so that decisions are based on data rather than assumptions. This pattern extends far beyond SAP and appears in almost every core platform modernization. I have analyzed this dynamic further in this post on LinkedIn.

Rewriting Code is Not Enough—Whether Done Manually or with AI

Many enterprises have begun modernizing their legacy code bases, with an increasing number leveraging generative AI for rewrites. While this helps, it only addresses a single layer of a much broader problem.

The remaining legacy footprint. The rewritten code often continues to share the legacy databases and data formats, meaning the coupling to the rest of the landscape remains. It has simply been relocated. Batch jobs, point-to-point integrations, and legacy reports reappear late in the transition phase, where they are most expensive to remediate. Release committees, testing gates, and team boundaries still reflect the old platform structure, resulting in modern code being delivered at legacy speed.

A lack of business ownership for rules. Rewriting code means either copying business logic that no one understands or changing it without a business owner to validate the requirements. This process requires stakeholders from outside IT.

Nothing actually gets shut down. New services are deployed while the old platform is kept running to support a few remaining dependencies. The enterprise pays for both, and licensing and support agreements continue to run.

AI makes code generation inexpensive, which shifts the bottleneck. AI translates what the code does, not what the business actually needs; as a result, an exact copy of a 20-year-old design remains the same design. Verifying that the new version behaves identically to the old one takes far longer than generating the code. Furthermore, AI only analyzes the inputs it is provided; execution schedules, workarounds, and contractual terms exist outside the codebase. A pilot project on a well-understood module may run smoothly, but the tangled, undocumented remainder is where programs stall. Large volumes of generated code that no one fully understands can easily become tomorrow's legacy.

AI is highly valuable for documenting what existing code does, generating tests, mapping dependencies, and accelerating execution once the target architecture and migration sequence have been defined. AI can accelerate a plan, but it cannot formulate it.

How to Begin

An organization does not require a five-year program to start. Success requires executing four steps in the correct order.

1. Map before you plan. Build a connected model of what the system does, what it depends on, and who owns each component, prioritizing integrations. This model does not need to be perfect; it simply needs to illustrate key dependencies. The model must be linked to live data and updated continuously; otherwise, it will be obsolete before it is completed.

2. Analyze the contract calendar. Renewal dates, termination notice periods, and licensing terms are often the real drivers or blockers of an exit strategy. Architects rarely review contracts, and licensing specialists rarely review architecture. Aligning these two perspectives usually makes the decommissioning sequence obvious.

3. Leverage regulation to build the business case. Under DORA and NIS2, unsupported platforms, dependency on key individuals, and third-party risk are liabilities that must be managed and documented. This provides a financial justification for decommissioning that "improving agility" never could.

4. Determine the strategy per system: retire, wrap, or retain. Not every legacy system needs to be replaced. Some are stable, cost-effective, and fully functional. The objective is to identify which systems to decommission, which to wrap behind modern interfaces, and which to retain—a decision that requires hard data on cost, risk, and business value rather than intuition.

The Legacy System is a Symptom

The legacy system itself is rarely the root cause of the problem. It is a symptom: an organization that has lost visibility into its own technology landscape while the cost of inaction grows quietly, one license renewal and workaround at a time.

Enterprises that succeed in moving forward rarely start with the most ambitious target state. They begin by making their current landscape visible, subsequently converting decommissioning into a series of small, funded, and low-risk decisions.

Which system in your current landscape does everyone agree should be retired, and what is realistically holding it in place?

📅 We welcome your insights at clariox.dk/contact

The information regarding Zeiss is based on coverage by Bloomberg on September 7, 2026.