VB6 migration target: desktop or web application?

Migration from Visual Basic 6 is no longer a question of if. Microsoft ended VB6 mainstream support in 2005 and extended support in 2008, and the runtime has degraded with each major Windows release since. The current question for IT directors and CEOs running a VB6 migration project is which target platform to migrate to. Two practical options exist: a modern .NET desktop application built on WPF or current WinForms, and a web application built on ASP.NET Core with Razor Pages. Both are .NET, and both run on supported Microsoft platforms that will outlive VB6 by decades. The choice between them is not technical fashion. It is operational fit.¹

PCG has been migrating VB6 applications since VB6 was current software and has executed migrations to both desktop and web targets across more than 500 production engagements in 31 years of practice. The decision framework below comes from that engagement history. It identifies the five operational factors that determine which target fits a given application, and it documents the situations where the apparently modern choice produces a system that frustrates the team that has to use it every day.²

Why does the target platform decision matter when both are .NET?

Both targets share a runtime, a language, a tooling chain, and Microsoft's long-term support commitments. Technical foundations are identical. Operational behavior is profoundly different, and the difference shows up in how the application is used every day, how it is deployed and updated, what it can connect to, and how it survives infrastructure changes.

A web application runs on a server. Users access it through a browser. Updates happen in one place. New users join by visiting a URL. Hardware access is constrained by browser security models. Operation requires connectivity between the user's device and the server. A desktop application runs on each user's machine. Updates require deployment. New users require installation. Hardware access is direct through the operating system. Operation continues when network connectivity drops. Neither set of properties is universally better. They serve different operational realities, and matching the wrong set of properties to a business's reality is the migration mistake that costs the most to fix later.

The cost of choosing wrong is not the migration cost itself. It is the cost of running a migrated application that does not fit how the business operates: workarounds that staff invent to compensate for the architectural mismatch, integrations that have to be rebuilt because the chosen platform cannot reach the hardware the workflow requires, deployment burden that the IT team did not anticipate, or connectivity dependencies that fail at the worst possible moments. Choosing the right target during the audit phase eliminates that cost entirely.²

When does VB6 to .NET desktop (WPF or WinForms) still win?

Desktop targets win when the application's operational reality includes any of three conditions. Each condition is independently sufficient. A VB6 application that hits one of them is a candidate for desktop migration regardless of how appealing the web architecture might appear in isolation.

The first condition is the strongest signal. When a VB6 application is the only software that knows how to read the calibration data off a specific industrial balance, talk to a vendor-specific scanner through a proprietary serial protocol, or print to a label printer with a custom command set, migrating to web breaks the integration. The browser cannot reach the hardware the way the desktop application can. PCG has seen this scenario regularly across manufacturing, environmental field operations, and inventory management work where the VB6 application accumulated hardware integration over years of specific equipment purchases.³

When does VB6 to web application (ASP.NET Core) win?

Web targets win when the application's operational reality does not require any of the desktop conditions, which is the case for most VB6 applications PCG sees in 2026. Migration to ASP.NET Core with Razor Pages, Blazor, or a Web API plus modern front-end framework produces an application that is easier to deploy, easier to maintain, easier to extend, and easier to access from anywhere the business needs it.

The deployment advantage of web is the one that most often tips the decision for distributed businesses. A VB6 application running on 200 desktops across five offices requires IT to coordinate updates, validate installations, handle support tickets from machines that fall behind, and verify that every user is on the same version of the software. The same application as a web target updates once on the server. Every user is current the next time they refresh their browser. The IT operational burden drops materially, and the business stops having "what version of the app are you running" conversations with users who have a problem.²

What about hybrid: desktop client connecting to web services?

Hybrid architectures exist and PCG builds them when the operational reality requires them. A modern .NET desktop client that reads from local hardware and writes through a Web API to a server-side database combines the desktop strengths (hardware access, offline tolerance, keyboard responsiveness) with the web strengths (centralized data, easier reporting, simpler partner integration). This setup gives the business a single source of truth on the server while the user-facing application maintains the desktop characteristics the workflow needs.

The hybrid pattern fits situations where part of the workflow requires desktop and part requires web. Field staff capture data through a desktop client running on a tablet or laptop, with offline tolerance built in. Office staff run reports and review the captured data through a web interface against the same server-side database. Mobile users may access a third interface optimized for their devices. All three connect to the same backend data layer through Web APIs that PCG builds during the migration.

Hybrid carries additional architectural complexity, and PCG only recommends it when the operational case requires it. A single VB6 application migrated to a single target (desktop or web) is simpler to build, simpler to maintain, and simpler for the business to operate. Hybrid is the right answer when the business genuinely has two or more distinct user populations with different operational needs from the same data. When the user population is uniform, a single-target migration produces a better outcome.³

How do hardware dependencies in the original VB6 application affect the choice?

Hardware dependencies are the single strongest determinant of target platform selection. PCG categorizes VB6 hardware dependencies into three tiers during the audit, and each tier carries a different implication for the migration target.

First tier dependencies are direct device control: the VB6 application uses COM components, ActiveX controls, or vendor SDKs to read from or write to hardware connected to the user's machine. These dependencies almost always force a desktop target. The hardware vendor's SDK was written for Windows desktop applications, not browsers. Recreating equivalent capability in a web target typically requires either browser-side helper applications that defeat the simplification web is supposed to provide, or hardware replacement that adds significant cost and risk to the migration scope.

Second tier dependencies are network-attached hardware: printers, scanners, or measurement devices that the VB6 application reaches through TCP/IP rather than through directly-attached hardware. These dependencies can migrate to either target. A web target reaches the network-attached device the same way a desktop target does, through standard network protocols. The decision between desktop and web for these applications falls to the other four factors rather than to the hardware dependency. Network protocols are sufficiently standardized that browser-to-device communication works reliably in either architecture.

Third tier dependencies are file system access: the VB6 application reads from or writes to specific file locations, watches folders for incoming data, or generates output files for downstream systems to consume. These dependencies migrate to either target, with the web target typically using cloud storage or a controlled server-side file system rather than user-machine local files. The migration involves redesigning the file flow, which is a scope item the audit identifies and documents.¹

What does the target platform decision actually cost the business?

The decision affects three categories of cost across the application's productive life: build cost, deployment and maintenance cost, and operational cost.

The migration cost itself is comparable between the two targets for equivalent application scope. The ongoing operational cost diverges based on user distribution, deployment frequency, and hardware integration scope.

Web applications generally produce lower ongoing IT cost for distributed user populations because deployment happens once per release rather than once per user per release. Desktop applications generally produce lower ongoing operational cost for hardware-integrated workflows because the integration does not require browser workarounds or hardware replacement. The right comparison is total cost across the productive life of the application, not the migration cost alone. PCG's audit documents both for the specific application under review.²

How does PCG make the recommendation during the audit phase?

PCG's VB6 audit produces a written target platform recommendation as part of the audit deliverable. The recommendation comes from a documented evaluation of the application against the five operational factors above, not from a default preference for either architecture. Audit deliverables include the reasoning behind the recommendation, the alternatives considered, and the trade-offs the business accepts by choosing the recommended target.

An audit phase typically completes in 2 to 3 weeks for a single-module VB6 application and longer for multi-module systems. During the audit, PCG works with the application's current users, reads the existing codebase, identifies hardware dependencies, documents the workflows the application supports, and assesses the data layer the application connects to. The target platform recommendation is the final synthesis of that work, supported by the underlying findings.

Businesses that choose to proceed with the migration use the audit document as the project specification. Those that pause after the audit own the target platform recommendation as a planning asset regardless of when migration begins. The audit is a deliverable on its own, not a commitment to a subsequent project.³