A developer pressing her forehead while working through old code

It works. That’s exactly why it never gets fixed.

The cost of staying put compounds quietly, until something forces the decision.

Most companies run at least one application they can’t afford to lose and can’t afford to rebuild. It keeps the business working, which is exactly why modernization is hard to fund: nobody wants to invest while the old system still does its job.

Meanwhile, a familiar set of problems builds up:

A black box.
The engineers who wrote the code have often retired, documentation is thin, and only a few people understand how it works.
Cut off from everything else.
Legacy applications don’t integrate easily, so data sits in silos that hurt analytics, privacy, and compliance.
Moving expectations.
Users expect mobile access, regular updates, and compliance by default, and unsupported code can’t deliver them.
A maintenance line that only goes up.
Specialists for aging platforms get more expensive as the supply of them shrinks.
A roadmap on hold.
AI agents can only use software they can discover, access, and execute, and legacy integration is cited as a barrier to AI by about 28% of mid-market companies.

Modernization feels risky for good reasons. Leaders worry about cost, timelines, large-scale data migration, and disrupting systems that run critical operations, and many have already lived through a rewrite that ran over or never finished. But deferral isn’t free either. Every year adds code to migrate and subtracts engineers who understand it, which makes the eventual job harder and riskier.

Five signs it’s time to look.

Tick the ones that sound like your organization. Nothing is stored or sent anywhere.

Signs that an application needs modernizing

Tick whatever sounds familiar. There’s no wrong answer.

Where does your application fit?

GAP modernizes applications in two ways, depending on what you’re running. Pick the closest match to see which applies.

Two developers looking over an application's code on a laptop
  1. VELO is built for this.

    VELO modernizes the whole application onto modern .NET (Blazor) on Azure, with the business logic intact, at a price fixed before work begins. It has its own website with full details, including how to request an assessment.

    VELO’s site opens in a new tab.

    1 / 4

A rewrite is one option of several.

We assess before we recommend, and the answer often differs from one application to the next. The right path is rarely a one-size-fits-all rewrite.

  • Keep it running

    Maintain

    Some applications are fine as they are and just need to be kept current. We can maintain applications that are no longer supported, including code originally built by another vendor.

  • Move it as-is

    Rehost

    Move the application to new infrastructure without changing it. It’s fast, but it also leaves the code, its limitations, and its technical debt exactly as they were. Sometimes that’s the right call.

  • Move code and features to a new platform

    Replatform

    Carry the existing code and features onto a modern platform, gaining current runtimes and hosting without redesigning how the application works.

  • Clean up what’s there

    Refactor

    Optimize the existing code to remove technical debt, so it’s easier and safer to change.

  • Change the architecture

    Rearchitect

    Change the code and architecture to upgrade capabilities, for example by breaking a monolith into services and APIs that make business logic reusable.

  • Build a new version

    Replace

    Build a new application with tailored functionality, or adopt a packaged product where your application isn’t genuinely differentiated. If a package would serve you better, we’ll tell you.

  • Two colleagues reviewing an application's modernization options on screen

How the work happens.

Assessment-led and incremental: one application at a time, so the business keeps running while the software catches up.

  1. Assess the estate.

    Inventory the applications and score each on six drivers: agility, fit, and value on the business side, and risk, complexity, and cost on the IT side.

  2. Set objectives and readiness.

    Agree the outcomes, the sponsor, and the stakeholder plan, and identify the skills needed to run the result. We build upskilling and a short-term dip in productivity into the business case, so neither is a surprise.

  3. Choose the path for each application.

    Maintain, rehost, replatform, refactor, rearchitect, or replace, whichever the assessment supports.

  4. Modernize incrementally.

    Start with one application, understand its workflows and roles, and deliver in short cycles with user feedback. Each application after the first goes faster, because connecting your existing databases and business logic to the new system is already solved.

  5. Protect data, security, and integration.

    Plan data migration, including format conversion and ETL, so integrity holds. Build encryption into APIs, add automated monitoring, and keep old and new applications working together so users don’t notice the seams.

  6. Keep it current.

    After launch, GAP can maintain the application and keep it updated with the latest releases, so it doesn’t become the next legacy estate.

How we think about this work.

Engineers at their screens migrating legacy code
  • The right path for each application

    Many vendors offer one move, usually a lift to the cloud or a rewrite. We start with an assessment and match the path to each application.

  • Keep what makes you different

    We don’t start by changing your process. We understand how the application supports it, including roles, access tiers, and workflows, and preserve the custom functionality that makes your business unique.

  • A partner, not a project

    Our teams work across Java, .NET, Ruby, PHP, Python, and more, and can stay on after launch to maintain applications, add new ones, and keep the system current. One client relationship has lasted more than a decade.

  • AI-accelerated, human-accountable

    Every engagement runs on GAP’s AI Development Lifecycle (ADLC). Agents do the execution, and a GAP engineer directs the work, reviews the evidence, and approves at every decision gate.

Can an AI agent use your application?

We assess each application on a five-level scale of AI-ecosystem readiness, so you can see where it stands and what it would take to move up. Pick a level to see what it means.

An AI coding agent running on a laptop beside a developer's screens

If the goal is agentic features inside your product itself, our SaaS to Agentic Evolution service picks up from here.

On VB6, PowerBuilder, Access, or another legacy platform?

There’s a faster, fixed-price route for seven specific platforms, and it has its own home.

VB6 · PowerBuilder · Microsoft Access · WinForms · WebForms · Clarion · Delphi

For seven legacy platforms, GAP offers VELO, an agentic AI modernization platform that moves the whole application onto modern .NET (Blazor) on Microsoft Azure, with the business logic intact, at a price fixed before the work begins. It’s the latest chapter of more than 30 years of modernization work, including the original Visual Basic upgrade tooling that Microsoft shipped in the box, and over a billion lines of production code migrated.

The reason these applications stay stuck is that the usual options are bad ones. A hand rewrite is quoted in years and millions, with nothing shippable until the end. And coding assistants that work well on a single file tend to lose coherence on a whole application, returning code that compiles but is incomplete, with no signal that anything is missing.

How VELO works

  1. Discover. Inventory the estate: what’s there, what depends on what, and what’s been dead for a decade.
  2. Specify. Extract the business rules into plain specifications, independent of the old platform. For many clients it’s the first written record of how the system actually behaves.
  3. Modernize. Build the new application from those specifications, in parallel across domains, with logic in an API layer and a modern interface on top.
  4. Verify. Test every unit as it’s produced, so gaps surface during the run rather than during acceptance testing.

Your code is processed in an isolated environment and removed from GAP’s systems after modernization. It isn’t used to build or improve any model.

VELO has its own website with full details and an assessment request. The link opens in a new tab.

A good first step is an assessment.

Whether you have one application or fifty, start by finding out what’s there and what each one needs.

  • Modernization assessment

    An inventory of your application estate, each application scored on six drivers, AI-ecosystem readiness assessed, and a recommended path for each one with a phased roadmap. For applications on VELO’s seven platforms, the assessment also covers fit and effort.

  • Pilot application

    One high-value application modernized end to end, to prove the approach, establish the patterns, and speed up the rest of the estate.

  • Phased modernization program

    Application-by-application delivery across the estate: data migration, integration between old and new applications, security and compliance upgrades, and mobile-friendly interfaces.

  • Ongoing maintenance and managed evolution

    GAP keeps modernized and inherited applications current with the latest releases, builds new ones as needed, and continues to upgrade the system over time.

Two engineers assessing code on a tablet and monitors

Tell us which application worries you most.

Questions people ask before they start.

How do I know whether my application goes through VELO or your engineering teams?

If it’s on VB6, PowerBuilder, Microsoft Access, WinForms, WebForms, Clarion, or Delphi, and a modern .NET target on Azure works for you, VELO is built for it. Anything else, such as Java, Ruby, PHP, Python, or web and service-based .NET, goes through our engineering teams. If you’re not sure, or you have a mix, an assessment sorts each application onto the right path.

Our system still works. Why modernize now?

It does work, and that’s exactly why it stays on the roadmap for years. The question is what it costs to keep it that way, how many people can still change it, and what it’s blocking. If the answer is that it’s fine, an assessment will say so and you’ll have saved yourself the project. If not, you’ll know where the gaps are and what to do first.

We can’t afford the risk of a big rewrite.

Neither can we recommend one for most applications. We modernize incrementally: start with one application, keep the rest running, and deliver in short cycles with your users giving feedback. A full rewrite is only one of several paths, and often it isn’t the right one. For VELO-eligible platforms, the price is also fixed before work begins.

Can’t we just lift everything to the cloud?

Sometimes that’s exactly right, and we call it rehosting. It’s fast, but it leaves the code, the limitations, and the technical debt as they were. The assessment tells you which applications are fine to move as they are and which need more, so you spend where it matters.

We’ll use AI coding tools and do it ourselves.

Those tools are great for speeding up engineers, and we use agents ourselves. But modernizing an application is more than writing code. It means deciding what to keep, what to change, and in what order, migrating data without losing integrity, building security into APIs, and keeping old and new systems working together. On large code bases, assistants also tend to lose coherence and return incomplete work without warning, which is why our approach plans, decomposes, and verifies the work, and keeps experienced engineers reviewing it.

Can AI be trusted with our business-critical code?

Not if it means pointing a chatbot at a repository, and that isn’t what this is. With VELO, the business logic is extracted into specifications first, the new application is built from those specifications, and a dedicated verification agent tests every unit. You can review the specifications before any code is generated. Across all of our modernization work, a GAP engineer approves at every decision gate.

Our processes are unique. We don’t want to change how we work.

Good, because we don’t start by changing your process. We understand how the application supports it, including roles, access tiers, and workflows, and preserve the custom functionality that makes you different. We connect old and new applications so people can move between them without noticing the seams.

Another vendor built our applications and we’re stuck maintaining them. Can you help?

Yes. GAP can take over and maintain applications that are no longer supported, including code originally built by another vendor, and keep them current with the latest releases.

My platform isn’t on the list. Can you still help?

Very likely. VELO covers seven specific platforms, but our engineering teams modernize applications across many others. Tell us what you’re running.

About Gap
Overview
Services
Services
Industries
Insights
Insights