Legacy Modernization — Making Old Software Future-Ready 2026

In roughly 70 percent of the mid-market companies we have audited, at least one mission-critical application runs on technology that is between 15 and 30 years old — VB6, VB.NET, Delphi 7, AS/400 with RPG, classic ASP, old PHP monoliths, Access with Excel VBA. These systems often carry the core of the business's value creation, which is precisely why they were left untouched for two decades. For management, CFOs and IT leadership this is acutely relevant in 2026 for three reasons: first, the talent market for legacy languages is drying up and a single developer departure can bring operations to a standstill; second, platforms such as Windows Server 2012/2016 and older .NET Framework versions are losing vendor support; third, GDPR, NIS2 and cyber insurers demand documented patch levels that legacy stacks are often structurally unable to achieve. This article shows what an economically viable modernization looks like — from the assessment through the 4R strategy and the Strangler Fig pattern to a realistic phased plan. For broader context, see our Software Development Guide.

Why 2026 Is When the Legacy Wave Hits Hard

The discussion is not new — what is new is the simultaneous convergence of three mutually reinforcing pressure factors. First, skills scarcity: the talent market for Visual Basic, Delphi, RPG, COBOL and classic ASP is effectively empty. Anyone searching for a VB6 developer in 2026 will find specialists approaching retirement — or nobody at all. The few candidates command day rates comparable to modern .NET or TypeScript developers, and often higher. This fundamentally changes the economics of "staying on the old stack."

Second, vendor roadmaps. Microsoft has not actively maintained Visual Basic 6 since 2008; extended support for many .NET Framework versions has ended; Windows Server 2012 R2 lost extended support in October 2023, and Windows Server 2016 is headed for the same fate. Embarcadero keeps Delphi alive, but every version requires licensing investment that is hard to justify for an isolated legacy system. IBM continues to support AS/400, but the number of developers with productive RPG expertise decreases measurably every year. Staying on an out-of-support platform means accepting unpatched security vulnerabilities and a growing gap with the rest of the IT landscape.

Third, regulatory pressure. GDPR Article 32 requires "measures to ensure the security of processing" — supervisory authorities increasingly interpret this as an obligation to keep software in a patchable state. NIS2 raises requirements for availability, incident detection and supply-chain security to a level that a typical VB6 monolith is structurally incapable of meeting. Cyber insurers explicitly ask in application forms about the support status of operating systems, databases and runtime environments. A "no" means premium surcharges or exclusion of certain damage categories — both more expensive than the modernization itself.

Typical Mid-Market Legacy in Germany

Despite all the sectoral variety, the same technical picture recurs with striking regularity among German mid-market businesses. The following overview summarizes the five most common legacy patterns — covering roughly 80 percent of legacy systems encountered in practice.

Stack	Typical Use Case	Main Risk 2026
VB6 / VB.NET (older framework)	Vertical industry solutions, ERP extensions, workshop software	Skills scarcity, no web capability, COM dependencies
Delphi 7 to XE	Machine control systems, medical/legal practice software, commercial tools	Licensing costs, 32-bit binding, no cloud connectivity
AS/400 / IBM i with RPG	Logistics, wholesale, manufacturing, bank back-office	Rapidly shrinking developer pool, 5250 UI, interface gaps
On-prem PHP monoliths (PHP 5.x / early 7.x)	Custom-built shops, portals, vertical administration systems	Outdated libraries, security vulnerabilities, no API layer
Microsoft Access with Excel VBA	Commission calculation, reporting, scheduling, "shadow IT"	Data integrity, multi-user issues, no auditability

A recurring observation: the most business-critical legacy system is often not the obvious industry tool, but the Excel file with 40 worksheets and VBA macros that has grown over years in the accounting department. This "shadow IT" is typically undocumented, depends on one person and contains calculations found nowhere in any ERP. A rigorous assessment therefore begins not with the largest system, but with the one carrying the highest risk per hour of downtime.

Assessment — Before You Write a Single Line of Code

Modernization projects fail not from poor execution, but from an insufficiently honest stocktaking of what exists. Before any technical concept, management and IT leadership need answers to five questions per application. This framework can be completed in four to eight weeks.

• Code Quality and ReadabilityHow many developers — in-house or reachable on the market — can understand the code? Do coding standards, version control and build automation exist? We measure this with a brief code tour: three senior developers are given a typical bug report and asked to locate the probable cause. If they need more than two hours, readability is critical.
• Test Coverage and Regression SafetyDo automated tests exist? If so, what is the coverage? In most legacy applications, coverage is zero — and this is the single most important finding because it severely constrains the modernization strategy. With no tests, the rule is: no refactoring until a test harness has been built retroactively.
• Documentation and Implicit KnowledgeHow much business knowledge lives in people's heads rather than in documents? How many of the original developers are still on staff or reachable? An application with two remaining knowledge holders and no documentation is a concentration risk of the first order.
• Domain Value and Business CriticalityWhat share of revenue or core processes does this application carry? What does one hour of downtime cost? One day? Applications with high domain value deserve refactoring or a controlled rewrite; applications with low domain value are candidates for Replace or Retire.
• Technical Risk and Support StatusIs the runtime environment still under vendor support? Are security patches available? How current are the libraries? An application running on an out-of-support platform with high business criticality is an emergency, not a project.

This assessment produces an application landscape map — a matrix of domain value versus technical risk. Each application lands in a quadrant with a standard strategy. This map distributes modernization budget across two to three years in a rational way.

The Four Strategies — Rewrite, Refactor, Replace, Retire

Once the assessment is complete, the choice of strategy is the most important decision. The 4R model — Rewrite, Refactor, Replace, Retire — structures it along the axes of business value and effort.

Strategy	When Appropriate	Typical Duration	Risk Profile
Refactor	Code is readable, team knows the language, technology has support, business requirements are stable	3–9 months	Low — existing functionality is preserved
Rewrite	Technology without vendor support, no capable team, or fundamental business realignment	9–24 months	High — feature gaps and overruns are the norm
Replace	Standard functionality, a market-available SaaS or ERP module covers 80%+	3–12 months	Medium — customization pain, lock-in risk
Retire	Application is barely used, function can be handled another way	1–4 months	Low — provided the data archive is properly secured

The most common wrong decision in practice is "Rewrite," because it feels intuitively attractive — finally a clean architecture, a modern language, fresh code. In reality, pure rewrites exceed their originally planned budget by over 100 percent in more than half of cases, and roughly one in four projects is abandoned before completion. The reason: two decades of implicit domain knowledge are embedded in the old application, undocumented anywhere, and laboriously rediscovered during the rewrite. We therefore almost always recommend that rewrite projects adopt a Strangler Fig mode — incremental migration alongside the legacy system, rather than parallel greenfield development followed by a Big Bang cutover. Related considerations can be found in our cluster articles on Monolith vs Microservices and Custom Software vs Off-the-Shelf Solutions.

The Strangler Fig Pattern

The Strangler Fig pattern described by Martin Fowler in 2004 is today the de facto standard for low-risk modernization. The name comes from the strangler fig tree, which grows around an old tree and gradually replaces it. Applied to software: the legacy system keeps running in production while a routing layer progressively redirects new requests to newly built components.

The process follows a recurring loop. First, a clearly delimited business domain is identified — for example "master data: customers" or "commission calculation." A self-contained component for this domain is built in the new system. A routing layer — typically an API gateway or reverse proxy — is placed in front, deciding per request whether the old or new code responds. Initially the request runs in parallel through both worlds and the results are compared. Once parity is stable over several weeks, the routing switch is flipped. Only after one to three months without any anomaly is the old code block removed.

This methodology has three advantages over Big Bang. First, the business remains productive at all times — no weekend cutover. Second, risk is small because only one bounded area is migrated at a time. Third, the parallel comparison mode provides empirical validation — deviations become visible before they can cause production damage. The trade-off is transitional complexity: two systems running in parallel, a routing layer, dual-write logic.

Anti-Corruption Layer and Data Migration

One challenge with the Strangler Fig pattern is the semantic break between the old and new worlds. The legacy system has developed data models over the years that do not fit the new architecture — cryptic column names, hardcoded mappings, overlapping concepts. Carrying these structures over unchanged would forfeit the value of the modernization.

The solution is an Anti-Corruption Layer, a translation layer between the old and new worlds. It translates data and calls into the clean vocabulary of the new system and back again. This layer costs additional development time, but it protects the new system from inheriting the structural weaknesses of the legacy world.

Three patterns have proven effective for data migration. First, classic ETL pipelines — extract, transform and load data at a defined cutover date, suitable for one-time transitions. Second, dual-write — simultaneously writing to both old and new databases during the transition period. Third, Change Data Capture — event-driven synchronization via database logs using tools such as Debezium, the most powerful approach for large data volumes. Those who underestimate data migration often fail right here — inconsistencies are discovered weeks after the cutover when reports no longer add up. For more on cloud migration patterns, see our Cloud Migration Guide.

Building a Test Harness Retroactively

The most important technical prerequisite for any substantial modernization is a safety net of tests. In most legacy applications, automated coverage is zero — without a test net, every change is Russian roulette. Two types of tests have proven effective for retroactive coverage.

Approval tests — also known as snapshot tests — compare the output of a function against an approved reference result. They are suitable for reports, billing calculations and complex logic whose correctness no one can trace in detail anymore, but whose output is accepted as "correct." You feed the function with real production inputs, save the outputs, and from that moment any unplanned change triggers an alert. Approval tests can be set up in a matter of days without fully understanding the underlying logic.

Characterization tests document actual behavior — including known quirks and bugs that have become features in practice. They are the foundation that ensures refactoring or Strangler Fig migration does not change anything unnoticed. Producing them is the most important task in the first weeks of any modernization project.

AI-Assisted Legacy Modernization in 2026

With the large language models of the 2024–2026 generation, three application areas in modernization are production-ready. First, reverse engineering: a modern model reads a 1,500-line VB code block and produces in seconds a readable business description, sequence diagrams and a list of external dependencies. This documentation is never one-hundred-percent accurate, but it is a dramatically better starting point than a blank Word document.

Second, test generation. Models propose approval and characterization tests from legacy code, often with well-chosen inputs and edge cases. The result is a first draft, not a finished test suite, but the speed of building a test net increases by a factor of three to five.

Third, code translation — for example from VB.NET to C# or from classic PHP to TypeScript. Here models perform well but not flawlessly — business logic subtleties, data type conversions, date handling and locale issues are the most common error sources. Fully automated migration without senior review almost guarantees subtle errors that surface weeks later in reports. The realistic productivity gain from AI is 30 to 50 percent — significantly better than skeptics claim, significantly worse than vendor slides suggest.

A Realistic Phased Plan over 6 to 18 Months

Mid-size modernizations follow a recurring sequence. The timeline below describes a typical Strangler Fig trajectory for approximately 100,000 lines of code, 50 to 200 users and a medium data volume.

• Weeks 1–4: Assessment and StrategyBuild the application landscape map, conduct stakeholder interviews and code tour, evaluate the five criteria from section 3, make the strategy decision using the 4R model, select the target stack. Deliverable: a twelve-to-twenty-page strategy document as a management briefing.
• Weeks 5–12: Test Harness and SpikeBuild approval and characterization tests for the critical 20 percent of functionality; conduct a technical spike for a small, clearly bounded business domain; set up the build pipeline and routing layer. Deliverable: a first live new-system module running in parallel comparison against the legacy system.
• Months 4–9: Main Migration in WavesSix to twelve business domains are migrated in successive waves. Each wave follows the same pattern: implement, run in parallel, compare, switch routing, retire old code. Data migration runs in parallel via dual-write or Change Data Capture.
• Months 10–14: Consolidation and OptimizationThe remaining smaller business domains are migrated; the Anti-Corruption Layer is decommissioned; performance optimization, data cleansing, user and operations training.
• Months 15–18: Completion and DecommissioningFull decommissioning of the legacy system, final data archiving in accordance with retention periods, handover to steady-state operations, retrospective for the next modernization wave.

The effort distribution surprises many executives. Pure programming work rarely accounts for more than 40 percent. Assessment, test harness, data migration and training together make up the larger block. Those who plan modernization purely as a development project regularly underestimate the total budget by 50 to 80 percent.

How We at Reepa Support Modernization Projects

Our approach is deliberately measured: we begin with a four-week assessment engagement in which we deliver the application landscape map, 4R recommendation and an initial strategy document — before any development decision has been made. This assessment is intentionally small in scope, because it is the most important investment before any larger budget is released.

In the implementation phase, we take on one of three roles depending on the situation: full modernization as general contractor; mixed teams combining the client's domain knowledge holders with our senior developers; or a pure advisory role covering test harness, architecture reviews and AI tooling selection while the client's own team implements. Which role fits depends on internal capacity and strategy — a Refactor strategy can be executed internally, while a Strangler Fig rewrite requires more senior experience than most mid-market companies can provide.

Technologically we are broadly positioned: from the legacy stack we typically modernize toward .NET 8/9, modern PHP, Java or TypeScript. The selection does not follow trends, but the availability of developers in the German market — the most important metric for maintainability in 2026 is not the coolness of the language, but the number of developers who can use it productively.

Frequently Asked Questions