by Olman Quesada, on Oct 21, 2026, 1:33:51 PM
Better models give modernization teams more to work with. Here’s how that progress translates into a working application.
OpenAI’s latest reported results are encouraging for anyone working with legacy software. On its COBOL migration benchmark, GPT-6.1 Sol scored 86.6% at low reasoning effort, compared with 5.4% for its predecessor at the same setting. With more reasoning effort, it reached 97.9%. On a separate benchmark, GPT-6 Astra passed 89.4% of tests in Visual Basic, up from 27.5%.
For teams maintaining older applications, improvements like these open up useful possibilities. Code that was difficult for a model to interpret or translate becomes more accessible, giving engineers a better starting point for modernization.
The next question is what that means for your application. If you’re responsible for a VB6 or PowerBuilder system that has been running the business for 25 years, you need to know how much work remains, what might change and how you’ll verify the result.
That’s where the details of the existing system start to matter: its calculations, dependencies and the business decisions buried in the code.
What to check in your own application
Take a financial calculation written in VB6. Its Currency type is a scaled 64-bit integer with four decimal places. Translating it to a floating-point double changes how values are represented and can introduce rounding differences. The code may compile and look fine in a quick test, while discrepancies show up later in invoices or month-end reconciliations. A migration needs tests that catch that kind of change.
Then there’s everything connected to the code. A production application can span forms, COM components, stored procedures, reports, batch jobs and integrations. You need to understand those dependencies and test the workflows that cross them. A successful translation of one file is useful evidence, but it only covers part of the system.
Some of the hardest questions involve decisions nobody documented. A workaround might exist because of a state tax change in 2004. An unusual output format might be exactly what a downstream partner expects. A model can help engineers investigate that code; confirming what still matters often requires someone who knows the business.
As models improve, more of this work can be accelerated. Teams still need a way to turn those improvements into changes they can test, review and deploy.
Decide what the business needs from the change
Preserving existing behavior is often the first priority, especially when the application handles money or supports daily operations. Moving to a supported platform can be a worthwhile outcome on its own.
Modernization also creates an opportunity to revisit awkward workflows. Which steps still serve a purpose? Which exist because of an old technology constraint? Where do users spend time working around the application? Answering those questions helps the team decide what to preserve and what to improve, without turning every migration into a complete redesign.
How we approach the work with VELO
At GAPVelocity AI, we use VELO, our agentic modernization platform, to combine AI agents with deterministic refactoring engines.
VELO scans legacy source, maps dependencies and helps size the modernization effort. Deterministic transformations handle established code patterns consistently, while agentic workflows support the broader translation work. The aim is to get teams to a compiling codebase and working UI early, so they can begin checking real workflows. The time it takes depends on the application and its dependencies.
Where the engineering team comes in
As the converted application takes shape, engineers work through the questions that need closer attention: whether a business rule has been preserved, how an integration should work and whether the architecture will be practical to maintain.
Our AI Squad brings GAP engineers and solution architects into that process alongside VELO. They review the output, investigate differences and work through decisions with the customer’s team. That collaboration is especially valuable when the source code and people’s understanding of the application don’t quite agree.
Checking behavior against the existing system
To check for behavioral changes, the AI Squad uses differential validation: running the legacy and modernized applications side by side and comparing their calculations, data and business logic. When results differ, engineers investigate why. Some differences are defects to fix; others may reflect an intentional change that needs the customer’s agreement. Testing the workflows the business relies on gives the team evidence for those decisions.
Getting ready for production
Production preparation also includes reviewing security, authentication, integrations and deployment. Depending on the application, that can mean replacing legacy authentication with OpenID Connect, using OAuth 2.0 for authorization and adding automated tests to the CI/CD pipeline. Architecture decisions belong here too, including whether approaches such as domain-driven design fit the system. These choices should support how the customer plans to operate and maintain the application.
Putting better models to work
Progress on legacy languages gives modernization teams more options. It’s a reason to revisit projects that once looked too expensive or difficult, and to test what today’s tools can do with your own code.
The useful next step is to choose a representative part of the application, identify the behavior that must be preserved and see how the modernized version performs. That gives you a much clearer basis for planning the larger project.
That’s how we bring VELO and the AI Squad together: use automation to move the work forward, then give engineers and customers something concrete to evaluate.
Want to explore what that could look like for your application? Start with a VELO assessment.
