by Cheyenne Sokkappa, on Aug 9, 2026, 12:00:00 AM
Most conversations about PowerBuilder modernization start with age. The platform is old, the vendor support is thinning, the developer pool is shrinking. All true, and all beside the point.
Age is not what makes PowerBuilder hard to modernize. Specific architectural decisions, made decades ago for good reasons at the time, are what make it hard. Here are the five that matter most, and what it actually takes to work around each one.
1. DataWindow Objects
Challenge: A single DataWindow bundles the SQL query, the presentation layout, computed columns, and validation rules into one proprietary object. No target platform has an equivalent construct, so there is nothing to translate it into directly. It has to be taken apart.
Solution: That separation is a purpose-built extraction step in our VELO modernization process. Before any code gets rewritten, the query logic, the presentation layer, and the validation rules are pulled apart into their actual components. The result is not a DataWindow-shaped object forced into Blazor. It is query logic, UI logic, and validation logic, each rebuilt where it belongs.
2. Embedded and Dynamic SQL inside PowerScript
Challenge: PowerBuilder applications routinely mix SQL statements directly into event scripts, alongside the business logic that surrounds them. Data access and business rules were never separated in the original code, which means separating them now carries real risk. Get it wrong and logic quietly disappears in translation.
Solution: We address this with a validation step built into the pipeline itself. As logic is extracted and rewritten, the output is checked against the original source behavior. Anything incomplete or inconsistent is flagged and corrected before it moves forward, rather than surfacing as a defect after the fact.
3. PowerScript's event-driven language model
Challenge: PowerScript has no direct equivalent in C# or .NET. Its syntax and its event model have to be reinterpreted, not transpiled. This is where GenAI tends to fall apart, because a general-purpose model working alone tends to lose track of earlier context by the time it reaches later parts of a file.
Solution: Our approach uses specialized agents assigned to different parts of that reinterpretation, working from a shared, maintained context instead of each starting from scratch. The goal is that logic reinterpreted early in a file is still accounted for by the time the rest of the file is processed.
4. Global variables and non-visual objects
Challenge: Long-lived PowerBuilder applications tend to accumulate global variables and shared non-visual objects that connect screens in ways that are not visible from looking at any single window. This is why modernized applications can pass initial testing and still break once they reach production. The coupling was always there. It just was not visible.
Solution: Before conversion begins, we map dependencies across the codebase, not just within individual modules. A change to shared logic touched by five different screens is understood as a change that affects five screens, not treated as five isolated edits.
5. Compiled PBL and PBD libraries
Challenge: PowerBuilder source code lives inside compiled binary libraries, not plain text files. You cannot simply open the code and read what it does. That alone makes it difficult to scope a PowerBuilder project honestly before committing to a timeline or a price, which is exactly the problem most PowerBuilder modernization efforts run into first.
Solution: This is what our free code assessment tool, ByteInsight, is built to solve. It has been built to read compiled PowerBuilder libraries directly, giving real visibility into the application's structure and logic before any commitment is made. A comprehensive assessment identifies what needs to be done and makes the modernization project a little less daunting.
What this means for your PowerBuilder App
Each of these five problems has historically pushed PowerBuilder modernization toward one of two outcomes: an open-ended rewrite with a headcount-driven timeline, or a generic AI tool applied to code it was never built to understand. Neither gives a business a number it can plan around.
Solving these problems directly, rather than working around them, is what makes it possible to quote a fixed price before work begins instead of billing by the hour as issues surface. It is also why the process moves faster than a manual rewrite. VELO delivers PowerBuilder modernization 20x faster and at 60% less cost than a manual rewrite, with the scope defined up front instead of discovered along the way.
Getting started
Check out some of our resources for PowerBuilder:
- Demo Github Repo - look at the modernized code yourself: Demo VELO PowerBuilder App
- Live demo of the modernized app with VELO
- Video of the before and after screens
VELO for PowerBuilder is available now as part of the GAPVelocity AI platform. If your organization is weighing the future of a PowerBuilder application, or if you are evaluating modernization approaches more broadly, we would welcome a conversation about what VELO can do for your codebase.
Ready to get started?
FAQ
What happens to my database?
Inline SQL, stored procedures, and database cursors are migrated to Entity Framework or direct ADO.NET data access patterns. Azure SQL is one of the supported output targets, so the data layer is in scope rather than left untouched. Your specific back end and the depth of stored procedure logic are sized during ByteInsight.
What about PFC, third-party controls, OCX components, and Windows API calls?
These fall into the manual portion of the project. Custom controls without direct Blazor equivalents, third-party integrations that need rewiring, and edge cases in DataWindow behavior are handled manually, either by your team or by AI Squad at a fixed price. The assessment at the beginning of your engagement identifies which of your dependencies fall into this category before you commit.
How is converted logic validated when we have no automated tests?
VELO helps build a test suite as part of the process and manually, we also test based on a behavioral equivalence harness that checks the converted application against the behavior of the original. The tests are conducted continuously as the migration proceeds, so a divergence is caught in the run that introduced it rather than during a test cycle at the end or after cutover. Test generation is part of what the platform produces.
How much is automated, and what does my team need to do?
VELO is expected to automated 85%-95% of the application, depending on the complexity. The remainder covers custom controls, third-party integrations, DataWindow edge cases, and functional testing. Your team can handle that phase or hand it to AI Squad. We know what that percentage will be when we conduct the assessment on your application.
How long does a project take?
This varies but you can generally expect 8 to 16 weeks total for a mid-sized application, to get to beta ready, meaning the code runs and compiles and some testing is complete.
Which PowerBuilder versions do you support?
We support all PowerBuilder versions.
