The Failure Mode of AI PowerBuilder Migration

Preserve Behavior, Not Just Code 

There's a particular kind of modernization failure that never shows up in a demo.

Nothing "broke." That's what makes it dangerous. The code was translated faithfully, line for line, and the behavior still diverged. This is functional regression, and in a legacy migration it is the failure mode that actually costs you; not the compile errors, which are loud and get fixed on day one, but the silent disagreements between the old system and the new one that surface weeks later, in production, on the numbers that matter most.

If you're modernizing a PowerBuilder application, this is the risk you need to manage.

Translation is the easy part

For most of the last three decades, the hard part of a legacy migration was the sheer mechanical labor of rewriting code. That's changed. AI can now translate PowerScript into C# at a speed and volume no team of contractors could match. The generation problem is largely solved.

The verification problem is not.

The industry is starting to name this out loud. Sourcegraph has described what they call the "80% problem" in agentic coding: AI agents reliably handle the visible 80% of a task, the part you can see in the diff, and miss the invisible 20% that lives outside their context window. The diff looks clean, the tests pass, you merge it, and days later something downstream you never told the agent about starts failing. At Microsoft Build this year, the entire framing around the Foundry platform was that the enterprise AI contest is now about reliability, not raw capability getting agents to hold up under real load, real data, and real compliance requirements, not just produce plausible output.

We've been calling this the 70% wall: the point where a naive AI translation gets you most of the way and then plateaus, because the remaining work isn't more code. It's correctness. And correctness in a legacy system is defined by twenty years of accumulated behavior that no one fully documented and, in many cases, no one still working there fully remembers.

Push past that wall with more generation and you don't get fidelity. You get the hallucination tax: confident, well-formatted C# that looks right, reviews clean, and is wrong.

PowerBuilder's hardest surface: the DataWindow

Every legacy platform has one construct that concentrates the risk. In PowerBuilder, it's the DataWindow and it's where behavioral fidelity is hardest to preserve.

A DataWindow is way more complicated and rich than a grid. It's a dense runtime that fuses stuff that modern architectures deliberately separate:

• Business logic embedded in presentation. Validation rules, required-field logic, and cross-field constraints live inside the DataWindow object itself, not in a service layer where you'd think to look for them.
• Computed fields and expressions. DataWindow expression syntax has its own evaluation semantics, its own null handling, and its own quirks around implicit type coercion. A computed column that "just adds two fields" may be relying on conversion behavior that has no clean equivalent in C#.
• Retrieval and update logic. The DataWindow manages its own change tracking, buffer states (primary, delete, filter), and update ordering. Reproducing what it does is straightforward; reproducing when and in what order it does it is where regressions hide.
• Event-model timing. ItemChanged, ItemError, and the rest fire in a specific sequence, and real applications depend on that sequence, often accidentally. Translate the handlers correctly but change the timing and you've changed the behavior.

This is why a line-by-line translation of a DataWindow-heavy application can be 100% faithful to the source code and still wrong. The source was never the specification. The behavior was. And the behavior includes edge cases the original developers never wrote down because they never had to. The system simply did the right thing, and everyone moved on.

Behavioral equivalence as a first-class engineering goal

If the source isn't the spec, what is? The running system. The only defensible target for a migration is behavioral equivalence: the modernized application, given the same inputs, produces the same outputs and the same side effects as the legacy one including the edge cases nobody documented.

That's an engineering discipline you design the migration around from the first day, and it looks like this:

• Characterization ("golden master") testing. Before you change anything, you capture the legacy system's actual behavior across a broad range of real inputs: the reports it produces, the values it writes, the records it rejects. That captured behavior becomes the specification the new system has to satisfy. You're not testing against what the app was supposed to do; you're testing against what it actually does, which is the only thing your users depend on.
• Differential testing. Run the legacy application and the modernized application against the identical input set and compare outputs field by field. Every divergence is either a defect to fix or a legacy quirk you've made a deliberate, documented decision to keep. Both are fine. What's not fine is a divergence nobody noticed.
• DataWindow-level fidelity checks. Because DataWindows concentrate the risk, they deserve targeted verification: computed-field values, validation outcomes, filter and sort results, and update sequences checked against the original, not just eyeballed in a rendered screen.
• Regression as a gate, not a phase. Behavioral equivalence is checked continuously as the migration proceeds, so a divergence is caught in the run that introduced it, while the context is fresh, instead of during a big-bang test cycle at the end, or worse, in production a month after cutover.

None of this replaces AI. It's what makes AI safe to use at scale for something as unforgiving as a system of record. Generation gets you speed; a behavioral-equivalence harness is what turns that speed into something you can actually put your name on.

How VELO approaches it

This is the core of how we built VELO, and it's why we don't treat modernization as a pure-generative problem. VELO pairs AI with deterministic analysis. The AI does what AI is good at; the deterministic layer handles the parts of a PowerBuilder application: DataWindow semantics, type behavior, event ordering where close enough is a defect, not a rounding error. The two together are what get you past the 70% wall to behavioral fidelity, instead of stopping at plausible.

It's also why every VELO engagement starts with the VELO Assessment. The Assessment analyzes your actual application and tells you what percentage of it VELO can modernize, grounded in the real code, before anyone commits to anything. From there, VELO delivers a fully modernized .NET and Blazor application on Azure at a fixed price. A working application, verified against the behavior of the one it replaces.

We come by this discipline honestly. Our lineage runs back to ArtinSoft, the team that built Microsoft's original Visual Basic Upgrade Wizard, the tooling Microsoft itself shipped to move VB6 code forward. Thirty years of migrating mission-critical, regulated systems teaches you one lesson above all others: customers don't remember how fast you moved. They remember whether the new system did the right thing on the numbers that mattered.

That lesson shows up in the work. GAPVelocity AI has modernized billions of lines of code and thousands of projects. We have a long list of customers and case studies that prove we've seen it all and been there, done that.

The question to ask any migration vendor

If you're evaluating how to modernize a PowerBuilder application in 2026, the market will offer you a lot of ways to translate code quickly. Speed is table stakes now. So the question that actually separates approaches is a different one: 

How do you prove the modernized application behaves the same as the one it's replacing including the edge cases we never wrote down?

If the answer is "the code is a faithful translation," that's a 70%-wall answer, and the other 30% is going to find you in production. If the answer is a behavioral-equivalence discipline: characterization tests, differential comparison against the running system, targeted DataWindow verification, you're talking to someone who understands what they're actually being asked to preserve.

Preserve behavior, not just code. It's the only definition of a successful modernization that survives contact with month-end.

Want to see what behavioral fidelity looks like on your application? Start with a VELO Assessment. We'll analyze your PowerBuilder codebase and show you exactly what percentage VELO can modernize, grounded in your real code, at no risk.