Visual Basic 6 Migration to .NET: How to Modernize Legacy Apps Before They Break

Last updated: September 2026
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 mainstream support from Microsoft in 2005 and extended support in 2008.1 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.

Microsoft does support the VB6 runtime for the lifetime of the Windows versions it ships on, and that fact gets used to argue the platform is safe. The distinction that matters: the runtime is supported, the language and the development environment are not.1 The runtime keeps executing, yet it is frozen, with no new features, no 64-bit support, no modern Windows API access, and no security patches for the application code itself. What that adds up to is architecturally stranded, not supported. A VB6 application in 2026 runs on a runtime Microsoft will not remove, sitting on top of code no vendor will ever patch.

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.

What is actually breaking VB6 apps in 2026

  • 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 and 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.2

What has changed for VB6 users in 2026?

Three developments in 2026 have raised the cost of staying on Visual Basic 6, and all three point at the same pressure: the people who can maintain the code are disappearing.

  • The developers who built production VB6 systems are aging out. The average VB6 developer is now in their late 50s, and recruiting replacements is expensive and slow.3 When the last VB6 expert on a team leaves, the system becomes unmaintainable overnight.
  • The scarcity now shows up in the rate. Industry analyses in 2026 place experienced VB6 developer rates well above modern-stack rates, closer to a scarcity premium than a complexity premium.3 Every year of deferral means paying more for less available expertise.
  • The wider labor market makes it worse. ManpowerGroup's 2026 Global Talent Shortage Survey found that 72 percent of employers report difficulty filling roles, and legacy-specific skills are a shrinking subset of an already constrained pool.3

None of this stops a VB6 application from running today. What it changes is the exit price. The migration that felt expensive in 2022 is cheaper now than the same migration will be in 2028, because the expertise to do it keeps getting rarer.

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.

1. Application audit and logic documentation

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.

2. Architecture decision

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. If you are weighing the two paths, PCG breaks down the trade-offs in choosing a desktop or web target for a VB6 migration.

3. Data migration and database modernization

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.

4. Rebuild and parallel testing

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.

5. Training and documentation handoff

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. Documentation ranges from thin to nonexistent, and the people currently using the application can describe what it does from the outside, but nobody alive has read the code in years. If that describes your situation, here is what to do when your original developer disappears.

PCG starts from the source code itself. If source code is available, the audit process reconstructs what the application does from the inside out. When 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 harder case, where no source code exists at all, has its own reconstruction path.

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. By contrast, 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.

Wondering what your VB6 migration would take? PCG runs an audit first, then quotes a real scope and timeline off your actual codebase.
Book a 20-minute call

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.

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, and 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.

Key takeaways

  • The VB6 runtime is supported for the lifetime of the Windows versions it ships on, but the language and the IDE have been unsupported since 2008. The application code itself receives no security patches. Architecturally stranded, not safe.
  • VB6 migration is not line-by-line code conversion. Automated translators carry every original architectural problem into the new platform. PCG documents the business logic first, then rebuilds against that specification.
  • Who migrates a VB6 application when the original developer is gone? PCG does. It reconstructs the business logic from the source code, the compiled executable, the database schema, and user interviews before any rebuild starts.
  • Most VB6 applications migrate to C# .NET Core 8 with an ASP.NET Core web front end, or to modern WPF when hardware or offline needs require a desktop app. The target comes from the audit, not a default.
  • Most migrations run 8 to 20 weeks. Documentation state and data quality drive the timeline more than anything else, and a planned migration costs far less than an emergency one.
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 Now
Frequently Asked Questions
Our VB6 application still works fine. Why migrate now?+×
Because the migration costs significantly less when it is planned than when it is forced. A VB6 application running on current hardware is one Windows update or one hardware refresh away from a failure that requires emergency response. The cost of a planned migration is predictable. The cost of an unplanned failure is not, and it always arrives at the worst possible time.
We do not have the original source code. Can PCG still migrate the application?+×
Yes, though it takes longer and costs more than a migration with full source code. PCG works from the database schema, the compiled executable behavior, and user interviews to reconstruct the business logic before rebuilding. The result is the same: a documented modern application that does what the old one did. The path to get there is longer when the source code is gone.
Will the new application look and work the same as the current VB6 system?+×
The business logic and data will be identical. The interface will be modernized, which is one of the benefits of the migration. PCG works with staff during the design phase to preserve workflows that people are accustomed to while eliminating the interface limitations that come with VB6 forms. The goal is a system that feels familiar in how it works, not one that looks exactly like software built in 1999.
Can we keep using the system while the migration is happening?+×
Yes. PCG migrates in parallel. The existing VB6 application stays in production throughout the migration. The new system is built and tested against real data before any cutover happens. Validation runs on real historical data before the old system retires. Staff do not see the new system until it is ready, and the old system does not retire until everyone is confident the new one is working correctly.
How does PCG handle custom reports and print layouts that exist in the VB6 application?+×
Every report and print layout in the existing system gets documented during the audit phase. PCG rebuilds them in the new platform, typically using SSRS, Crystal Reports for .NET, or a web-based reporting layer depending on what the application requires. Reports that are used regularly get priority attention during parallel testing to confirm outputs match.
What if requirements have changed since the VB6 application was built?+×
The audit document becomes the starting point for a conversation about what the new system should do, not just what the old one did. Most clients have a list of things the VB6 system never did well that they have been working around for years. PCG builds those improvements into the new application as part of the migration scope, not as separate change requests after the fact.
Do we own our data after the migration?+×
Yes. All your business data and historical records belong to you and are fully exportable at any time, with documentation of how the data is structured. PCG hosts and maintains the new application and recommends a support retainer after go-live, but your data is yours from day one of go-live and is never locked into a fixed product.
What platform does PCG migrate VB6 applications to?+×
Most VB6 applications migrate to C# .NET Core 8 with an ASP.NET Core web front end built in Razor Pages. Applications with specific desktop requirements, such as direct hardware integration or offline operation, may migrate to a Windows desktop application built in modern WPF. The recommendation comes from the audit, not from a default preference. PCG has been building in .NET since its first release and in C# since 2002.
About the Author

Allison Woolbert

CEO and Senior Systems Architect, Phoenix Consultants Group

"VB6 migration is not technically difficult for someone who knows the platform. The hard part is the business logic that got baked in over 20 years by people who are no longer there to explain it. That is where migrations fail, not in the code translation. PCG has been doing this long enough to know where to look for the logic that nobody documented and everybody depends on."

Allison's experience in software development goes back to the early 1980s, predating PCG's founding in 1995. She has spent decades solving the hardest data problems in business, working with Fortune 500 corporations, growing mid-size firms, and small businesses across industries ranging from manufacturing and fleet management to healthcare staffing and regulatory compliance.

FireFlight Data System is the product of everything she learned: a purpose-built platform designed to eliminate the structural failures she encountered and fixed throughout her career.

Sources

  1. Microsoft Visual Basic 6.0 support lifecycle documentation. Microsoft ended mainstream support for the IDE in 2005 and extended support in 2008. Per Microsoft's VB6 support policy, the runtime remains supported for the supported lifetime of the Windows versions it ships on, while the language and development environment are not. learn.microsoft.com
  2. PCG project data, 1995 to 2026. Emergency migration engagements triggered by system failure average 40% higher cost than planned migrations of equivalent scope.
  3. Developer age, rate premium, and hiring difficulty: industry analyses of the VB6 labor market, 2026, and ManpowerGroup 2026 Global Talent Shortage Survey (72% of employers report difficulty filling roles).
This article is informational and does not constitute legal, security, or compliance advice for any specific situation. Migration decisions depend on the particular application, its data, and its regulatory context. Phoenix Consultants Group, founded in 1995, recommends a direct review of your application before acting. Consult a qualified professional for guidance specific to your circumstances.