Legacy desktop and client-server applications silently run many critical pieces of enterprise businesses. They barely stay alive and running, while the platform underneath them ages out of support, the developers who wrote them move on, and the cost of modernizing rises over time.
The decision to modernize is rarely forced by an outage. It is forced by the accumulating risk of depending on a system that few people understand, built on a framework the original vendor no longer invests in, and by a cloud strategy that a desktop-bound application cannot participate in.
Moving these applications to the cloud is not a single act of relocation. It is a sequence: assess the architecture, select a migration strategy, then execute the migration, typically onto cloud-native .NET. Each stage depends on the one before it, and the most expensive mistakes come from starting in the middle.
Most legacy modernization programs are scoped before anyone understands what they are actually modernizing. A team commits to a target framework, a timeline, and a budget, and only discovers the true shape of the application once conversion is underway. That sequence is backwards, and it is the single most common reason modernization efforts miss their intended benefits.
The assessment problem is not unique to any one source technology, but it is acute in the desktop and client-server estate. Applications written in VB6, PowerBuilder, and Microsoft Access were built over years or decades, often by developers who have since left, and the business rules that run the organization are frequently entangled with the user interface rather than separated into a maintainable layer. In first-party research across 1,105 organizations evaluating modernization, VB6 remained the dominant source technology at 67.6 percent (State of Legacy Modernization Report 2026), which tells you how much of the installed base still runs on a platform whose original tooling and expertise are disappearing. What is missing is a current, accurate account of what the code does and its dependencies.
This is where an architecture assessment earns its place at the front of the program. Gartner has long advised that a comprehensive cloud-native readiness assessment is a precondition for a sound migration, and that organizations skipping it tend to make decisions inflight simply to get the application running, which leads to misalignment with the project's stated goals.
Gartner's own framework for classifying applications, the set of migration options spanning rehost, refactor, revise, rebuild, and replace, is not a menu you can choose from responsibly until you have assessed each application against its business objectives.
A credible assessment produces three things, each of which de-risks a decision you would otherwise be making on assumption:
The reason this stage comes first is that everything after it depends on the quality of what it produces. A migration strategy chosen without a dependency map is a strategy chosen blind. An execution plan built on an undocumented understanding of the business logic is a plan built on assumptions that conversion will expose one by one. The assessment is the highest-trust, lowest-risk phase of the entire program, and it is the phase most often compressed or skipped in the rush to show progress.
The consequence of skipping it is not hypothetical. Gartner has predicted that more than 70 percent of mainframe exit projects initiated in 2026 will fail to produce their intended benefits, driven in large part by organizations overestimating what generative AI tooling can do with complex legacy code. That finding is about mainframe environments rather than desktop applications, but the underlying failure mode is the same across the legacy estate: teams commit to an execution approach before they have assessed what the code actually contains.
GAPVelocity AI offers a legacy application assessment with VELO, it's agentic AI platform, as a standalone engagement for organizations at this stage. It produces the dependency map, the documented account of the application's logic, and the per-application complexity profile that a modernization program needs before a single line of code is converted. It is available as a discrete first step, without commitment to a full modernization, so the decision to proceed is made on evidence rather than estimate.
Once an application has been assessed, the strategy question becomes tractable. The market presents this as a choice between tools, but that framing is misleading. The real decision is about approach, and the two approaches that matter for moving desktop applications to the cloud are automated code conversion and hybrid modernization. Most vendor content argues for whichever one the vendor sells. A sound decision requires evaluating both against what the assessment found.
Automated code conversion translates the source application into .NET more or less as it stands, preserving the existing structure and behavior while changing the underlying framework. Microsoft's own tooling sits in this category: the .NET Upgrade Assistant is the reference utility for moving projects onto current .NET versions, and it is the baseline any serious conversation about conversion should acknowledge. Conversion is the right approach when the assessment shows an application whose structure is sound and whose logic, while dated, is coherent. It is faster and less disruptive than rebuilding, and it aligns cleanly with a move to the latest version of .NET as the target framework. Its limitation is that it carries the existing architecture forward, including the parts that were entangled to begin with.
Hybrid modernization takes a mixed path. Rather than converting an application wholesale or rebuilding it from nothing, it decomposes the application, converts what can be converted, and rebuilds the parts where the existing structure would not survive the move intact. This is the approach the assessment points to when business logic is deeply entangled with the user interface, or when a portion of the application needs to be re-architected to work in the cloud rather than simply relocated there. It is more involved than straight conversion, and it depends heavily on the quality of the dependency map and the complexity profile produced during assessment.
The distinction that matters is not which approach is better in the abstract. It is which approach the assessment points to for a given application. An organization with a portfolio of legacy applications will often need both, applied selectively: straightforward conversions for the applications that can take them, hybrid modernization for the ones where the assessment revealed structural problems that conversion would only carry forward.
Both approaches target current .NET, and for a modernization program the sound target is the latest long-term support release. Microsoft alternates between long-term support versions, which carry a multi-year support window, and standard-term releases, which are supported for a shorter period. For legacy modernization specifically, the long-term support release is the appropriate target: it gives a freshly modernized application the longest runway before it faces another framework upgrade, which avoids the situation where a program lands on a version that reaches end of support shortly after go-live. Confirm the current long-term support version and its support timeline at the point of strategy selection, and commit to it deliberately rather than defaulting to whatever version happens to be in hand during execution.
The execution stage is where the strategy meets the code, and it is where the current wave of AI tooling has changed both what is possible and what can go wrong. General-purpose AI coding tools can translate legacy code, and they can do it quickly. What they struggle with is doing it reliably at the scale and complexity of a production application, where the logic that matters is buried in decades of accumulated behavior and the cost of a silent error is high.
This is the failure mode Gartner identified when it predicted that most 2026 mainframe exit projects would miss their intended benefits: the gap between what generative AI tooling promises for complex legacy code and what it delivers in practice. Generic large language model tools tend to perform well on the straightforward majority of a codebase and then stall on the intricate remainder, the parts where the business logic is densest and least documented. On a production application, that remainder is precisely the part that cannot be gotten wrong.
Agentic AI migration is a response to that problem, but the response only holds if the AI is governed rather than turned loose. The distinction is between running a codebase through a general-purpose model and hoping the output is correct, and running it through a pipeline where deterministic analysis does the structural work first and AI operates within boundaries that analysis has already established. In a governed approach, the application's structure, its symbol tables, its inheritance relationships, its data access patterns, is analyzed deterministically before any AI touches the code, so that the AI is working with a documented account of the application rather than inferring it.
The purpose of this structure is to keep the business logic and the application's observed behavior intact through the move. When the deterministic analysis has documented how the application behaves before conversion begins, that documented behavior becomes the reference the converted application is validated against. The move to the cloud changes the framework and the deployment model; it should not change what the application does. A governed pipeline is what makes that a checkable claim rather than a hope.
This is the approach GAPVelocity AI takes with VELO, its agentic AI modernization platform. VELO is delivered as a managed service or a self-service platform you can run on your own. With the managed service, the team runs the customer's application through the platform, with deterministic analysis establishing the structural account of the application before AI-assisted conversion operates within it, and validation checking the result against the documented behavior. The output targets cloud-native .NET on Azure. Whether it's run by the team or on your own, the governance is built into the platform rather than something the customer has to impose themselves.
The three stages are sequential for a reason, and the sequence is also the answer to where a modernization program should begin. The assessment is the foundation. It is the lowest-risk, highest-value stage, it is the one that makes every subsequent decision defensible, and it can be run as a discrete engagement before any larger commitment is made. An organization that assesses first can choose a modernization strategy on evidence, execute it with the business logic documented, and validate the result against a known account of how the application behaved before the move.
GAPVelocity AI's Technology Architecture Assessment via VELO is available as that first step. It produces the dependency map, the documented business logic, and the complexity profile that a sound modernization program depends on, without requiring a commitment to the full program before the findings are in.