VB6 to .NET desktop vs VB6 to web application is decided by five operational factors: hardware integration requirements, offline operation needs, user distribution geography, deployment infrastructure capacity, and the business workflow's natural form. Most VB6 applications migrate well to web. Specific use cases continue to require desktop. The right answer depends on the operational reality, not on technology preference.
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.1
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.2
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.2
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.
Direct hardware integration
The application controls or reads from devices connected to the user's machine: barcode scanners, label printers, balances and scales, serial port instruments, USB measurement devices, RFID readers, or proprietary hardware with vendor-supplied SDKs. Browser security models constrain hardware access in ways that often cannot match desktop reliability.
Unreliable or absent connectivity
Users operate in environments where network connectivity is intermittent, slow, or unavailable: loading docks, warehouse floors, remote sites, vehicles in motion, or facilities where IT has not extended reliable WiFi to the operational areas. Desktop applications continue running through connectivity gaps that would freeze a web application.
Data-entry intensive workflow with keyboard shortcuts
The application supports staff doing high-volume data entry where every keystroke matters: rapid form completion, keyboard-driven navigation, custom function key mappings, and immediate field-to-field movement. Desktop interfaces still outperform browsers on raw keyboard responsiveness and shortcut customization for power users.
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.3
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.
Distributed user base
Users access the application from multiple offices, remote locations, customer sites, or home offices. Web applications eliminate the deployment and version management overhead of supporting installed software across that distribution. One server, one URL, every user current with one update.
Reporting and consultative workflows
The dominant use of the application is reading data, building reports, analyzing trends, or making consultative decisions based on what the data shows. Browsers handle these workflows comfortably, and the visualization libraries available in modern web stacks exceed what desktop frameworks deliver without significant effort.
Integration with other web services
The application needs to exchange data with cloud services, SaaS platforms, partner APIs, or other web-based systems the business operates. Web architectures handle these integrations natively. Desktop applications can do this work too, but the integration patterns are more complex and less standardized than what web frameworks make available out of the box.
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.2
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.3
The decision is not desktop or web in isolation. It is which architecture matches the operational reality of how the business actually uses the application. PCG's audit determines that reality before recommending a target.
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.1
Speak directly with the engineer who would scope your VB6 audit
A free 30-minute consultation to evaluate which target platform fits your VB6 application. No obligation, no sales handoff.
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.
.NET desktop migration
WPF or modern WinForms target
- Build cost comparable to web for equivalent scope
- Per-user installation and update burden ongoing
- Hardware integration preserved without redesign
- Operates through connectivity gaps without failing
- Power-user keyboard performance preserved
- Server-side infrastructure not required
- IT support model focused on user machines
Web application migration
ASP.NET Core, Razor Pages, Blazor target
- Build cost comparable to desktop for equivalent scope
- One deployment serves every user instantly
- Hardware integration limited by browser security
- Requires reliable connectivity to operate
- Visualization and reporting libraries strong
- Server-side infrastructure required and maintained
- IT support model focused on server and access
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.2
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.3
Find out which target platform fits your VB6 application
A free 30-minute consultation, followed by a fixed-fee audit that produces a written target platform recommendation.
Web is the right answer for most VB6 migrations, but not all of them. Migrating an application to web that operationally needs desktop produces a system that frustrates the team that uses it. The correct framing is not modernity. It is whether the workflow actually fits a browser interface. PCG's audit determines the answer for each application rather than defaulting to the architecturally fashionable choice.
Direct hardware integration through serial port, USB device drivers, or proprietary SDKs is the strongest single signal that desktop is the right target. Browser security models limit hardware access in ways that often cannot be worked around without compromising the operational reliability the business depends on. PCG evaluates the specific hardware in scope during the audit and recommends the architecture that preserves the integration.
Web applications require reliable connectivity to the server hosting the application. In environments where connectivity is intermittent or unavailable, desktop applications continue working while web applications fail. The decision is operational, not technical. If the field reality includes loading docks, warehouse floors, remote sites, or mobile operations where connectivity cannot be guaranteed, desktop remains the safer target.
Modern .NET desktop applications built on .NET Core 8 with WPF or current WinForms run on a supported Microsoft platform that has a long lifecycle ahead. The compatibility problems that ended VB6 came from a runtime Microsoft stopped supporting in 2008. .NET Core 8 has a documented support lifecycle through November 2026 with long-term support releases following. Choosing desktop today does not commit the business to repeating the VB6 situation.
Yes. PCG's VB6 audit produces a written recommendation on the target platform as part of the audit deliverable. The recommendation is based on the application's actual operational profile rather than a generic preference. The audit stands on its own as a planning document. The business owns the recommendation regardless of whether PCG performs the subsequent migration.
1 Microsoft Visual Basic 6.0 support lifecycle documentation. Microsoft ended mainstream support in 2005 and extended support in 2008. learn.microsoft.com
2 Phoenix Consultants Group, Visual Basic 6 Migration to .NET. phxconsultants.com
3 Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business. phxconsultants.com
This article is informational and reflects PCG's experience executing VB6 migrations to both desktop and web targets since 1995. It is not legal, regulatory, financial, or technical advice for any specific situation. For guidance tailored to a particular VB6 migration scope, contact Phoenix Consultants Group directly. PCG was founded in 1995.
PCG migrates Visual Basic 6 applications to modern .NET. We have been doing this work since VB6 was current software, which means we understand what these systems actually do before touching a line of code. Most migrations take 8 to 20 weeks depending on application size and documentation available. Your business logic comes through intact. So does your data.
Why are VB6 applications failing in 2026?
Visual Basic 6 reached end of support from Microsoft in 2008. The runtime persisted through Windows compatibility layers, but that window is closing fast. In 2026, the failure points are stacking up: 64-bit Windows dropping 32-bit COM component support, third-party controls with no working installers, and hardware refreshes that simply will not run the old runtime environment at all.
The businesses still running VB6 applications are not doing so because they prefer VB6. They are running them because the application works and the migration felt expensive. Nobody wanted to touch something that was not broken. In 2026, more of those applications are breaking. A Windows update that rolled out silently at 2am is a common trigger. So is a new machine purchase where IT discovers the application will not install.
- 64-bit Windows environments removing legacy 32-bit COM support
- ActiveX controls with no current vendor support or installer
- Crystal Reports components tied to VB6 versions with no upgrade path
- DAO and RDO data access layers deprecated in current SQL Server
- Hardware refreshes where the VB6 runtime simply will not install
- Windows 11 compatibility breaks that appear without warning after updates
- SSL/TLS library dependencies that no longer function in modern network environments
The cost of waiting is no longer theoretical. Every month a VB6 application stays in production on modern hardware is a month closer to a failure that forces the migration under crisis conditions rather than planned ones. PCG has handled both scenarios. The planned migration costs significantly less.1
What does PCG actually do during a VB6 to .NET migration?
The migration is not a code conversion. Automated tools exist that will translate VB6 syntax to VB.NET syntax line by line, and the result is almost always unmaintainable code that carries every architectural problem of the original into the new platform. PCG does not use that approach.
The work starts with understanding what the application does. VB6 systems running for 15 or 20 years often contain business logic that exists nowhere else in the organization. Rules encoded in 2004 by a developer who is no longer there, handling edge cases that nobody currently remembers exist. PCG documents that logic before writing a single line of new code.
PCG reads the existing VB6 codebase and produces a plain-English document of what the application does and what business rules are embedded in the code. This becomes the specification for the new system.
Based on what the application does and how it is used, PCG recommends the target platform. Most VB6 applications migrate to C# .NET Core with a web front end. Desktop applications with specific hardware dependencies may stay as Windows desktop apps, rebuilt in modern WPF or WinForms. The decision is driven by the business need, not by what is easiest to build.
VB6 applications typically connect to Access databases or older SQL Server versions. PCG migrates the data to a current SQL Server schema, cleaning and normalizing records in the process. The new application connects to clean data from day one.
The new application is built against the documented specification. Before cutover, both systems run in parallel on real data. Discrepancies surface before the old system is retired. PCG does not do big-bang cutovers on business-critical applications.
Staff training on the new system, written documentation of how it works, and a support retainer option so PCG remains available after go-live. The goal is a team that can operate the new system without calling PCG for every question.
Can PCG migrate a VB6 application if the original developer is gone?
Yes. This is the most common situation PCG encounters on VB6 projects. The developer who built the system retired, changed careers, or passed away. The documentation ranges from thin to nonexistent. The people currently using the application can describe what it does from the outside, but nobody alive has read the code in years.
PCG starts from the source code itself. If source code is available, the audit process reconstructs what the application does from the inside out. If only a compiled executable exists, PCG works from the database schema and user interviews to reconstruct the business logic before any rebuild begins. That process takes longer and costs more, but the result is the same: a documented understanding of what the system does before migration work starts.
The technology stack PCG works in for these migrations is the same one the original VB6 systems connected to. SQL Server in every version from 6.5 forward. Access databases from every era. COM components and ActiveX controls are familiar territory for this team. So are the Crystal Reports versions that shipped alongside VB6.
How long does a VB6 to .NET migration actually take?
The honest range is 8 to 20 weeks for most applications PCG handles. A single-purpose VB6 application with a clean Access backend and good source code documentation can be migrated in 8 to 10 weeks. A large multi-module system built over 15 years by multiple developers, with no documentation and a database that has grown organically since 1998, takes closer to 20 weeks or more.
The variables that drive timeline more than anything else are documentation state and data quality. An application with a documented specification and clean relational data migrates in half the time of one where PCG has to reconstruct both from scratch. The audit phase at the beginning of every PCG migration is what makes timeline estimates reliable rather than guesses.
- Source code available
- Original developer reachable for questions
- Clean relational database
- Single application module
- Staff who can demonstrate every workflow
- No source code, compiled executable only
- No documentation
- Multiple modules built by different developers
- Data spanning decades with inconsistent formats
- Undocumented edge cases in production
How does PCG scope a VB6 migration?
PCG does not quote VB6 migrations without an audit. The cost of any migration depends on the size of the application and how well it is documented. Data cleanup requirements are scoped during the audit. That figure reflects 31 years of doing this work, not an estimate built from a sales conversation.
The audit engagement produces a written scope document with a firm project quote. Clients who want a number before the audit are getting a guess. PCG does not give guesses on work that will run a business for the next 15 years.
The comparison that matters is not migration cost versus zero. It is migration cost versus what the next emergency failure costs when the VB6 application breaks on a machine that will not run the runtime, two days before a deadline that cannot move. Schedule a free 30-minute consultation at phxconsultants.com to start the conversation.2
What happens to our data during the migration?
Data integrity is treated as non-negotiable on every PCG migration. The process runs on a copy of production data, never on live data, until the parallel testing phase confirms the new system produces correct results. Every record count is verified before and after. Every calculation the old system performed is tested against the new system's output on real historical data.
VB6 applications frequently connect to Access databases or early SQL Server versions with denormalized schemas and inconsistent data types. Records that accumulated formatting quirks over decades of manual entry are cleaned during the migration process. PCG cleans and normalizes data during migration rather than carrying the same problems into the new platform. The new system starts with data that matches what the new schema expects.
Clients receive a data migration report that documents record counts by table, any records that required manual review or correction, and the transformation rules applied. That report stays with the project documentation permanently.
Your VB6 application will not run forever.
PCG has been migrating these systems since before most of them were considered legacy. Start with a free consultation and get a firm scope and quote.
Contact PCG NowFrequently Asked Questions
1 Microsoft Visual Basic 6.0 support lifecycle documentation. Microsoft ended mainstream support in 2005 and extended support in 2008. Runtime compatibility with Windows 11 is not guaranteed and has degraded with each major OS release since Windows 10 version 21H2.
2 PCG project data, 1995 to 2026. Emergency migration engagements triggered by system failure average 40% higher cost than planned migrations of equivalent scope.
Phoenix Consultants Group | phxconsultants.com | Founded 1995.