by Cheyenne Sokkappa, on Apr 18, 2026 11:59:59 PM
A recap of the VELO live demo with Jeff Fritz, Kenneth Rivera, and Oscar Poveda
Last week, GAPVelocity AI joined Jeff Fritz on his live stream to demo VELO — an agentic AI platform that modernizes legacy applications to Blazor (.NET). We took a real MS Access database, ran it through the VELO pipeline live, and showed the output: a running web application, the generated source code, and what it looks like under the hood.
This post covers what happened, what questions came up from the audience, and a few things that surprised even us during the session.
Watch the whole video of the live event below!
What the audience was working with
Before diving into the demo, Jeff polled the audience about what legacy applications they were still running. The responses in chat covered a wide range: Access, VB6, PowerBuilder, ASP.NET WebForms, Clarion, .NET Framework apps, and FoxPro. One attendee shared they had 200 tables, 265 forms, 320 reports, and 200,000 lines of VB, built over 30 years. Another had a small Access database with 11 forms and 450 lines of VBA and wanted to know about cost. The audience was not theoretical about this problem.
Why Dealing with Legacy is Hard in the First Place
Kenneth covered three things the team has learned consistently across hundreds of modernization projects.
The talent problem. The developers who built these applications are retiring. VB6 and Access developers are not coming out of bootcamps or universities. The institutional knowledge about how these systems work, the edge cases, the workarounds, the logic that was never documented, goes with them when they leave.
The maintenance cost. Kenneth cited a figure he hears repeatedly from IT managers: 60 to 80 percent of their budget goes to keeping legacy systems alive. Licensing, infrastructure, components that cannot move to the cloud because of security constraints. That leaves almost nothing for building new things.
The limits of general-purpose AI. The team has run experiments with Copilot, Cursor, and Codex. The consistent finding is that these tools get you to roughly 70 percent of a working migration and then stall. The remaining 30 percent is where the hard problems live: the business logic, the database bindings, the patterns specific to how Access or VB6 or PowerBuilder actually work under the hood. As Kenneth put it: "If you don't go the right way, you're going to get a Frankenstein at the end."
How VELO works
VELO is an agentic platform, meaning it runs a coordinated sequence of specialized agents rather than a single general-purpose model pointed at the codebase.
Scout is the first agent. It inventories everything in the Access application: forms, tables, queries, macros, reports, VBA modules. Before any code is written, VELO knows exactly what it is working with.
Architect builds the foundation of the Blazor Server application based on what Scout found. It maps the Access schema to the target architecture and sets up the project structure.
Coder extracts the business logic from the Access forms and modules and converts it to idiomatic C# and Razor components. The separation of concerns is implemented from the start: business logic in the Services layer, presentation in Razor pages, data access through Entity Framework.
Quality runs validation passes to verify build integrity and functional parity. As Oscar noted, this can run as many iterations as the application requires.
The whole pipeline runs unsupervised. You upload the Access database, the agents work through the application, and you download a Blazor Server project when it is done.
What the Demo showed
Oscar ran the Northwind Access database through VELO live. The pipeline completed and produced a summary: 21 forms modernized, no reports found, data seeded from the original Access database.
The modernized application runs in a browser. Oscar did a side-by-side comparison with the original Access application. A few things stood out:
It is not a pixel-perfect replica, and that is intentional. The goal is not to reproduce the Access UI in a web browser. It is to produce a web application that follows modern conventions: responsive layout via Bootstrap, a proper navigation sidebar, web-standard tables and forms. Jeff noted that because Bootstrap is used, the application is inherently responsive, meaning it works on phones and tablets.
The code structure is clean. When Oscar opened the project in Visual Studio, Jeff recognized the structure immediately as a well-organized Blazor application: Components for pages and layouts, Models for Entity Framework, Services for business logic, Helpers for constants. No proprietary third-party libraries anywhere in the output. All NuGet packages are standard Microsoft packages, publicly available.
Entity Framework replaces Jet/DAO. The Access application used the old Jet database engine. The modernized application uses Entity Framework Core, which means the data layer is database-agnostic. Jeff walked through the implication: changing the database provider is a matter of swapping the EF Core provider in the NuGet packages and updating a connection string in appsettings.json. SQL Server, PostgreSQL, and Oracle all work.
The default is an in-memory database. For the initial output, VELO seeds the application from the Access data using an in-memory provider. This means the application runs and shows real data on first launch with no database setup required. If you want to connect a persistent SQL Server instance, you add the connection string and run a migration.
Audit logging is included. Oscar showed interceptors in the data layer that log creates and updates automatically, using aspect-oriented programming so audit logging does not clutter the business logic.
The Coverage Question
The most direct question of the session: how complete is the automated output?
Kenneth and Oscar were specific: VELO gets to 85 to 95 percent of automation. That number refers to code completeness, not production readiness. The code compiles. It runs. The business logic is there. What it does not include is production deployment, CI/CD pipeline setup, integration testing, new features the customer wants to add, and any customizations specific to their environment. That work is what GAPVelocity AI calls the last mile.
Oscar gave a concrete comparison. The Northwind database, done manually, took a developer a solid month to bring to the same state VELO produced in the demo. He mentioned a real customer whose team spent three months manually migrating one piece of a sales system before reaching out to GAPVelocity AI.
Questions from chat worth noting
"Does this assume the legacy app is cleaned up first?" No. Give them the application as it is. The reason: customers need a side-by-side comparison of original behavior versus modernized behavior. Cleaning the code before migration removes the baseline you need for that comparison. VELO handles removing obsolete dependencies and patterns as part of its process.
"Can I use this to get a base and then do the final work myself?" Yes. Kenneth described a self-service offering in development where you upload the application and receive the code to continue on your own. For the current release, GAPVelocity AI runs the migration on the customer's behalf. The output is described as alpha-ready: ready for users to test and provide feedback before the final polish. A self-service solution is expected to be ready for users in Q2 2026.
"What kind of Blazor app does it produce?" Blazor Server on the latest version of .NET (currently .NET 10).
"Does VELO handle the SQL Server front end / Access back end architecture?" The current release handles the standard Access application case. More complex configurations are on the roadmap.
"What about WebForms, Angular, React?" WebForms is handled through GAPVelocity AI's engineering team using existing deterministic migration tools while the agentic version is built out. Angular and React to Blazor migration is something the team has experimented with but is not on the active roadmap. PowerBuilder and VB6 are the next technologies being added to VELO, with a monthly release cadence planned.
Why Microsoft Foundry
VELO runs inside the customer's own Azure tenant. The source code never leaves their environment. The customer chooses which models to use within MS Foundry. All monitoring, logging, and auditability runs through Azure's existing tooling. For customers with an Azure MACC agreement, VELO consumption may apply against that commitment.
Kenneth's point on this was straightforward: for enterprise customers in regulated industries, the question of where the code goes is not optional. The architecture was designed around that constraint from the start.
Dive into the VELO Output Code Yourself
The generated source code from the Northwind demo is available at github.com/GAPVelocityAI/VELODemo.
The README covers how to open it in Visual Studio, how to run it with the in-memory database, and how to wire up a SQL Server instance if you want persistence. It runs out of the box with F5, no database setup required.
If you have a legacy Access application
ByteInsight is a free assessment tool that runs locally against your codebase. It gives you an inventory of what is in the application, an estimated automation coverage percentage, and a breakdown of what falls in the last-mile bucket. Nothing leaves your environment and it takes about 15 minutes to run.
Once you have the output, you can submit it through the MS Access modernization form and GAPVelocity AI will scope the engagement from there with fixed pricing based on your actual codebase.
Run the free ByteInsight assessment
About Our Speakers
Jeff Fritz is a Principal Program Manager at Microsoft and a fixture in the .NET developer community. He got his start in software working with Access databases in the late 90s, which meant he was asking the right questions throughout. His audience on Twitch and YouTube spans developers at every level, and the chat during the session was one of the most engaged we have seen.
Kenneth Rivera is VP of Engineering at GAPVelocity AI and has spent over two decades working through the specific problems that make legacy modernization hard. He covered the background on VELO, why it was built on Microsoft Azure AI Foundry, and what the team learned from years of doing this manually before AI made automation possible.
Oscar Poveda is a Solutions Architect at GAPVelocity AI and ran the live demo. He walked through the full VELO pipeline from uploading an Access database to downloading and running the modernized Blazor application, then opened up the code in Visual Studio.
GAPVelocity AI is the modernization division of Growth Acceleration Partners, a Microsoft Solutions Partner. VELO runs on Microsoft Azure AI Foundry.
