Replacing legacy software series, part 1: the introduction and the 6R approach

Definition of business-critical legacy software

Business-critical legacy software refers to applications and systems that were built and implemented between 15 and 25 years ago (roughly 1999-2009) that remain essential to daily operations. These systems serve as the backbone of core business processes.

These systems share common characteristics:

• Built using technologies prevalent at the turn of the millennium (Java EE, .NET Framework 1.x-2.x, Oracle Forms, Visual Basic 6, PHP 4/5, Classic ASP)
• Monolithic architectures (single, self-contained applications where all components are tightly coupled and must be deployed together)
• Limited or no API capabilities for modern integrations
• Running on infrastructure that vendors no longer fully support
• Containing business logic that's poorly documented or understood only by retiring employees

The fundamental difference between legacy and modern software extends beyond age to architecture. Modern applications are built with:

• Microservices that can be updated independently
• Cloud-native design allowing infinite scalability
• API-first approaches enabling seamless integration
• Containerization for portability across environments
• Continuous deployment capabilities for rapid updates
• Built-in observability and monitoring

Legacy systems were designed for a world of predictable loads, annual updates, and on-premise infrastructure. Modern systems assume constant change, variable demand, and distributed architecture.

The legacy challenge

The numbers, viewed from three perspectives, paint a sobering picture on both sides of the Atlantic:

Maintenance burden: at least 70% of business operations worldwide depend on systems that are more than ten years old. Forbes has noted that around 70% of enterprise data continues to run on mainframes, underscoring how deeply these systems remain embedded in global infrastructure (Forbes). Pragmatic Coders similarly reports that about 70% of the software stack used by Fortune 500 companies is over 20 years old (Pragmatic Coders). These figures highlight how dependent modern enterprises still are on technology that predates the smartphone era.

Skills: this dependence on older systems is made worse by a shrinking pool of experts who know how to maintain them. The average age of legacy system specialists is between 52 and 58 years, and around 10-15% of these experienced developers retire each year. Meanwhile, only about 30% of universities still teach legacy technologies such as Oracle Forms, older Java frameworks, or the .NET Framework. As a result, organizations face a mounting skills gap that directly threatens the stability of the very systems their operations depend on.

Innovation penalty: Legacy systems create clear obstacles for innovation. Around 44% of large enterprises say outdated systems hold back most projects (Inspectorio). McKinsey notes that organizations with high technical debt often see initiatives stall, spend about 40% more on maintenance, and deliver new features up to 50% slower than peers (McKinsey, Fullscale). It is also evident that these architectures cannot realistically support AI, advanced analytics, or hyperautomation. Monolithic design, outdated data structures, and poor integration make modern capabilities nearly impossible without major redesign, leaving organizations exposed to higher costs and competitive risk.

Why critical legacy software persists

First off: they work. Sometimes expensively but reliably. From a European bank executive I paraphrase: the core banking system has run for 23 years with 99.99% uptime. It processes 2 million transactions daily without fail. Why would I risk changing it?" This sentiment echoes across industries. These systems have been debugged over decades, their quirks are known, and their stability is proven.

Second, modern enterprises have legacy ecosystems. A single core system might connect to 50-100 other applications through middleware, custom interfaces, and batch processes built over decades.

Third, in regulated industries, systems are certified and validated. A validated system in pharmaceuticals or a compliance-certified system in finance represents millions in audit costs and years of regulatory approval. Changing them means re-certification, a process that can take years and cost more than the technology itself.

Replacement approaches: the 6R approach

When addressing business-critical legacy software, organizations face six primary strategies. These options apply equally to SMEs and large enterprises, though resource constraints may limit which approaches smaller companies can realistically pursue.

‍

‍

Understanding the context

• Rehosting applies to business-critical legacy systems when the main pain point is outdated infrastructure. It keeps the system intact but simply moves it to new servers or cloud, reducing costs while carrying forward all technical debt.
• Replatforming is relevant when small changes can unlock cloud benefits. It still preserves most of the legacy logic but tweaks parts of the stack so the system performs better in a modern environment.
• Refactoring becomes necessary when the code of a critical system has degraded. The business logic remains the same, but the code is cleaned up and modernized to make it maintainable and more efficient.
• Rearchitecting is a deeper step: it reshapes the structure of a legacy system into modern patterns like microservices. Unlike refactoring, this involves redesigning the way components interact, not just cleaning code. It enables scale and flexibility without rewriting every line.
• Rebuilding goes further than rearchitecting. Here the entire system is rewritten from scratch, keeping only the business requirements. While rearchitecting adapts the structure, rebuilding discards the old codebase entirely.
• Replacing applies when the legacy system is critical but not unique. Organizations adopt SaaS or commercial solutions to cover the function, accepting standardization in exchange for lower maintenance and faster deployment.
  
  

The ROI challenge

The hardest part of legacy replacement is working out whether the investment is worth it. ROI is about balancing short‑term savings with long‑term strategic gains. The financial side often includes lower maintenance bills, potentially reduced infrastructure costs when moving to cloud, fewer license fees, and leaner support teams. These benefits depend on how the migration is executed and how well the systems are optimized in their new environment. They may also generate revenue benefits such as faster time to market, improved customer experience, and the ability to offer new features like mobile access or AI‑driven insights.

The non‑financial side adds equally important considerations. A well‑executed replacement reduces security vulnerabilities and helps organizations stay compliant with regulation. It preserves knowledge that might otherwise be lost as older staff retire and ensures continued vendor support. Strategically, modern systems make companies more attractive to talent, more agile in responding to change, and more capable of innovating. ROI therefore covers not only financial metrics but also the preparation of the organization for resilience and growth in a digital economy.

‍

At Eli5 we created an ROI calculator that allows decision makers to explore different scenarios before committing to building their own software. The tool highlights key ROI metrics and helps clarify how costs, savings, and strategic benefits might balance out in practice. Try the calculator on this page.

What’s next in this series

This article is the first in a series on replacing legacy software. Future parts will build on these foundations and dive into specific challenges and opportunities:

• Decision trees for legacy software replacement. How to make structured choices between rehosting, refactoring, rebuilding, and other paths, and how to avoid common decision traps.
• Data migration. What happens to decades of business data during replacement, the risks involved, and how to design a migration strategy that preserves business continuity. Includes an interview with the CTO of Eli5.
• Vertical SaaS. In which cases replacing legacy software with industry-specific SaaS can be the smarter move, and when it pays to build your own.
• UX/UI design for business‑critical systems. Why user experience is the ultimate frontier for enterprise systems, and what it takes to design interfaces that employees actually want to use. With insights from the CEO and Product Lead of Eli5.
• AI agents. Why Microsoft CEO Satya Nadella’s claim that "Applications as we know them are going away in favor of agents" might redefine how we think about replacing legacy systems, and how this could influence your roadmap.

Together, these articles will form a practical guide: from deciding if, when, and how to modernize, to executing replacements, and preparing for the technologies that will shape the next decades of enterprise software.