What Legacy Code Are Companies Trying to Replace in 2026?

We looked at 1,105 modernization inquiries from a twelve-month period. Two-thirds of them named a language that shipped in 1998.

The size of the world’s legacy code estate gets estimated constantly and measured almost never. The numbers in circulation (billions of lines of COBOL, trillions of dollars of technical debt) come from surveys of enterprises that already know they have a problem. Those surveys rarely ask which technologies are actually running.

We had a different instrument available. Every organization that approaches GAPVelocity AI about modernizing an application tells us, on the intake form, what they are running. Over the twelve months from August 2025 to August 2026, 1,105 organizations answered that question. We've published the full distribution, the underlying counts and the sample limitations in a new report, The State of Legacy Modernization Demand 2026.

This is demand-side data, not a census. It shows what organizations are trying to leave, not what is installed worldwide. Within those limits, it answers something the estimates can't: when a business decides to move off legacy code in 2026, what's it moving off?

The headline numbers

• 67.6% named Visual Basic 6. 747 of 1,105 inquiries identified VB6 as the source technology. Twelve times as many as the next single technology.
• 83% named a technology first released before 2000. The wider Visual Basic family: VB6, VB.NET and Office VBA accounts for 73.4% of demand.
• 58% of demand came from outside the United States, across more than 120 countries (N = 9,636 inbound contacts).
• Microsoft Access grew fastest: 6.3x year over year, faster than any other tracked technology, while total identified workloads grew 3.3x.
• Demand spans 15 named source technologies. Clarion, a 4GL released in 1986, drew more inquiries than Delphi or Classic ASP.
• Weighted by code volume, VB6’s share falls from 68% to roughly 30%. Across 467 scoped applications, the median PowerBuilder codebase is eight times the size of the median VB6 codebase.
• VB6 applications were built close to the business. They were frequently written by domain experts in finance, operations and manufacturing rather than by professional development teams: scheduling, pricing, inventory, costing. Years of fixes and exceptions turned the code into a working record of how the business operates.
• A working VB6 application produces no pressure to move. The forcing function is almost always external: a Windows rollout, an acquisition, a compliance audit, a failed 32-bit dependency, or the retirement of the one developer who understands the system. Demand is lumpy and largely invisible until it surfaces as an urgent project.
• Small public training corpora. There is far less VB6, PowerBuilder or Clarion code on the open internet than Java or Python, and what exists is rarely paired with a modern equivalent.
• Heavy coupling between business logic and a proprietary GUI framework. The behavior of a VB6 application is spread across forms, event handlers, modules, COM references, control properties and deployment assumptions. Translating one procedure at a time leaves too much context behind.
• No canonical mapping to a modern target. There is no agreed answer to what a PowerBuilder DataWindow or a VB6 form should become. Target architecture decisions still require engineering judgment.

Visual Basic 6 is still the center of the market

Visual Basic 6 shipped in 1998. Mainstream support for the development environment ended in 2005 and extended support ended in 2008. Microsoft’s current position is that the VB6 IDE is unsupported, that core runtime files remain supported only for the lifetime of supported Windows versions, and that organizations should migrate VB6 applications to modern technology.

Eighteen years after the last patch, VB6 accounts for 67% of modernization inquiries. The second-largest single technology, VB.NET, accounts for 5.6%. PowerBuilder accounts for 5.2%. The distribution chart needs an 800-record axis because of one technology; every other bar sits below 63.

Two structural features explain the persistence, and both cut against the way legacy estates are usually estimated.

It is also worth separating runtime support from application support. Many VB6 systems depend on abandoned installers, 32-bit database drivers, COM components and third-party ActiveX controls. A supported runtime does not restore support for an abandoned control, and it does not make the original development environment maintainable.

Legacy is an architecture problem, not only an age problem

Plot each technology’s first release year against inquiry volume and the sample tilts heavily toward the 1980s and 1990s. But the exceptions on the modern end of the chart are as instructive as the cluster on the old end. C# accounts for 4.3% of inquiries and WinForms or WPF for a further 1.8%; 6.1% of demand for technologies that are neither old nor unsupported.

What drives those organizations is the architecture: thick desktop clients, WebForms postback models, direct database coupling, old framework dependencies, and deployment models that limit further development. Modern code and modern architecture are not the same thing, and buyers are asking for the second.

Legacy modernization is a global problem

Across 9,636 inbound contacts in the same period, 58.3% originated outside the United States. The United States accounts for 41.7%, India for 8.3%, the United Kingdom for 5.0%, Germany for 3.6% and Canada for 3.1%. Europe as a whole accounts for roughly 27%, and the distribution within Europe tracks enterprise software spend closely.

This matters because legacy modernization is frequently framed as a problem of American small and mid-sized businesses running shadow IT. The demand data does not support that framing. Legacy burden appears to track the general installed base of enterprise software rather than clustering in any single region or company size.

Microsoft Access is the fastest-growing source of demand

Comparing the twelve months to August 2026 against the preceding twelve months shows which stacks entered the modernization conversation fastest. Microsoft Access inquiries grew 6.3x from a small base, ahead of VB6 at 4.7x, VB.NET at 3.1x, PowerBuilder at 2.4x and Clarion at 1.8x. Total identified workloads grew 3.3x, so Access, VB6 and VB.NET all accelerated relative to the sample.

Access is also the stack organizations are least likely to volunteer that they depend on. It rarely appears in a managed application inventory, because it was rarely built by the people who maintain one.

The long tail is real, and it is underserved

Roughly one in three inquiries names something other than VB6, and demand spans 15 named source technologies. Clarion, a 4GL first released in 1986 and unknown to most modernization vendors, drew 31 inquiries, more than Delphi and more than Classic ASP.

Organizations in that group often face the hardest road. A business running Clarion or Informix 4GL confronts a market of effectively zero automated migration options, because tooling economics push every vendor toward the head of the distribution. The realistic choices have been a manual rewrite or continued deferral. This is the segment where general-purpose agentic tooling, rather than stack-specific converters, is most likely to change the economics.

Counting organizations is not the same as counting code

Inquiry counts measure how many organizations are trying to leave each stack. They say nothing about how much code each one is carrying. Across 467 modernization opportunities scoped between 2023 and 2026, the difference is large and consistent.

The median VB6 application scoped for modernization is about 124,000 lines of code. The median PowerBuilder application is 1,000,000 lines, roughly eight times larger. The median Clarion application is 1.3 million, more than ten times larger. The three Informix 4GL estates in the sample average 7 million.

Apply each technology’s median size to the 2026 inquiry mix and the picture inverts. Visual Basic 6 falls from 68% of organizations to roughly 30% of implied code volume. PowerBuilder rises from 5% to roughly 19%, and Clarion from under 3% to roughly 13%. On that measure the three enterprise 4GL-era stacks: PowerBuilder, Clarion and Informix 4GL represent more than a third of the code seeking a way out, from about 8% of the organizations asking.

This estimate is crude. It assumes the size distribution of scoped opportunities holds for inquiries that never reached scoping, which almost certainly overstates the tail. Even halved, the conclusion stands: the modal buyer and the modal codebase are not the same thing.

What this means for AI modernization claims

Generative AI has changed the economics of code analysis and transformation. It has also exposed the limits of simple code translation, and the demand mix above is exactly where those limits bite. Legacy technologies have three characteristics that make them harder for large language models to modernize.

A credible AI-led approach has to work at application scale: inventory hidden dependencies such as 32-bit COM components, preserve business behavior, handle known language and framework patterns consistently, generate maintainable target code that does not simply replicate legacy constraints, and test both compilation and semantic fidelity. Claims about AI-driven modernization should be evaluated against the stacks that dominate real demand, not the stacks that are easiest to demonstrate.

How we built this, and what it can't tell you

Source technology is self-reported by the requester on an intake form at the point of inquiry, selected from a fixed list with a free-text alternative. Each record is one inquiry about one application workload, not a completed engagement. The data has not been independently verified against source code.

The sample is skewed, and the report says so in detail. Microsoft funded and specified the original Visual Basic Upgrade Wizard, built by ArtinSoft and shipped inside Visual Studio .NET. Our lineage, ArtinSoft, Mobilize.Net, GAPVelocity AI has been the default destination for VB6 migration questions for more than two decades. Organizations leaving VB6 are more likely to find us than organizations leaving any other stack, so the 67.6% figure should be read as an upper bound for the wider market rather than a neutral estimate. Mainframe COBOL, SAP ABAP and mainframe-adjacent 4GLs are almost certainly under-represented.

The full report publishes every underlying count, states the limitations in full, and includes the complete methodology so that anyone can check the arithmetic or reweight the sample. We would rather be corrected than uncited.

What comes next

Demand data should lead to code-estate data. We intend to publish a companion report drawn from automated code assessments rather than sales scoping: measured application size by source technology, counts of third-party controls and COM dependencies, database access patterns, unsupported dependencies, common language patterns, and migration outcomes. Those benchmarks would give modernization teams a basis for planning, and give the industry a better picture of the legacy estate still in service.

Download the full report

The State of Legacy Modernization Demand 2026 runs 16 pages and includes the complete technology distribution, the full geographic breakdown, year-over-year comparisons, application-size data across 467 scoped opportunities, and the full methodology and limitations. Download the full report

See it work: VB6 to Blazor, live — 16 September, 11:00 AM ET

If VB6 is the stack you are trying to leave, we are modernizing a real VB6 application to Blazor on Azure in a live session on September 16. Legacy screens and Blazor output side by side, language-specific agents translating and validating against the source, and a look at the hard parts where legacy UI and business logic diverge, and how the output stays accountable.

Save your seat