COBOL Gets the Headlines. VB6 and PowerBuilder Are the Legacy Crisis Nobody's Watching.

The Legacy Estate Is Rarely Just COBOL

When people talk about “legacy modernization,” the conversation almost always defaults to mainframe COBOL — batch jobs, JCL schedulers, CICS transaction monitors, decades-old banking cores. That framing isn’t wrong, but it’s incomplete. Walk into most organizations old enough to have a COBOL estate, and you’ll usually also find a second, quieter legacy problem sitting one layer up the stack: Windows-era client-server applications written in VB6 or PowerBuilder sometime between the late 1990s and mid-2000s, still running the internal tool nobody wants to touch.

These two categories of legacy code get treated as separate problems by most tooling — mainframe parsers for one, .NET migration consultants for the other — even though, inside the org chart of the company running them, they’re frequently the same problem with the same cause: business logic nobody fully documented, written by people who’ve since retired, sitting in a language the current engineering team doesn’t read fluently. Legacy Dragon parses both, in the same AST-graph, same single binary, on purpose — because splitting the tooling by decade of origin doesn’t match how the risk actually shows up inside a real IT estate.

VB6 in 2026: Still Running, Increasingly Cornered

VB6 shipped in 1998, and by any reasonable accounting it should have been retired years ago. It hasn’t been. Coverage through 2026 keeps landing on the same conclusion: thousands of businesses still depend on VB6 applications in production, and Microsoft’s position has been to keep the VB6 runtime working on current Windows for existing applications, without extending that to new development, security patching, or 64-bit support.

That arrangement is getting harder to live inside of. Recent analysis of running VB6 on Windows 11 points to compatibility that has degraded with each major OS release since Windows 10 version 21H2, driven in part by 64-bit Windows dropping support for the 32-bit COM components a lot of VB6 apps depend on for their UI controls and integrations — components whose original installers, in many cases, no longer exist or no longer run. A hardware refresh that would be routine for almost any other application can be the event that finally breaks a VB6 tool that’s been quietly working for twenty years.

There’s a compliance angle here too, not just a compatibility one: PCI DSS v4.0 became mandatory on March 31, 2025, and it requires vulnerability management across all system components in scope — a requirement that’s awkward to satisfy for software built on a runtime that hasn’t received a security patch in over a decade. An application doesn’t have to be exotic to become a compliance liability. It just has to still be running.

PowerBuilder: The Vendor Itself Is Signaling How Big the Installed Base Is

PowerBuilder’s story looks different but points at the same underlying fact. Sybase (now part of Appeon) shipped PowerBuilder 2025 in May 2025 with features aimed squarely at organizations trying to modernize in place rather than rewrite from zero: codeless UI theming that can visually refresh a legacy screen without rewriting it, and automatic REST API generation that exposes existing PowerBuilder business logic to mobile and web clients without a rebuild. A vendor doesn’t invest in “modernize without rewriting” tooling unless the installed base still using the old apps is large enough, and valuable enough, to be worth serving directly rather than simply left to lapse.

The people who can read and safely change that PowerBuilder code are getting harder to find for the same structural reason COBOL talent is: it’s not what current computer science programs teach, and the engineers who learned it on the job in the 1990s and 2000s are the ones retiring now.

Japan’s Legacy Problem Isn’t Mainframe-Specific

This is where the picture connects back to why Legacy Dragon handles Shift-JIS, EBCDIC, and DBCS natively rather than assuming UTF-8. Japan’s METI convened a Legacy Systems Modernization Committee that ran from July 2024 through March 2025, drawing on a market-trend survey conducted between December 2024 and February 2025, and published its comprehensive report in May 2025. Coverage of that report and the broader “2025 Digital Cliff” concern has repeatedly cited a figure around 80% of Japanese companies still relying on legacy systems — a number that, by its nature, spans mainframe COBOL estates and Windows-era client-server tools alike, not one or the other. A parser that only reads COBOL is solving half of that inventory at best.

Why One Tool, Not Two

None of this means VB6 and PowerBuilder deserve the same modernization playbook as COBOL and JCL — the runtime risks, the migration paths, and the business context are genuinely different. What they share is the actual shape of the risk: undocumented logic, aging authors, and a system nobody wants to be the one who breaks. Legacy Dragon parsing COBOL, JCL, PL/I, Assembly, SQL/DB2, CICS, and REXX alongside VB6, VB.NET, and PowerBuilder — ten languages total, in one single binary, producing the same interactive AST graph regardless of which decade the code came from — is a bet that most organizations don’t actually need a mainframe tool and a separate Windows-legacy tool. They need one honest map of everything old that the business still depends on.

---

Carrying both a mainframe estate and a Windows-era client-server one? See how Legacy Dragon parses across all ten languages at dragon.aitytech.com, read more on the parsing bottleneck it was built to solve or why it ships as a single binary for locked-down environments, or reach us at [email protected].