Why are VB6 applications failing in 2026?

Visual Basic 6 reached end of support from Microsoft in 2008. The runtime has 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 that no longer have working installers, and hardware refreshes that simply will not run the old runtime environment at all.

The businesses still running VB6 applications are not running them because they prefer VB6. They are running them because the application works, the migration felt expensive, and 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.

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.¹

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 that have been running for 15 or 20 years often contain business logic that exists nowhere else in the organization. Rules that were 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.

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 source code is not available and only a compiled executable exists, PCG works with the database schema and user interviews to reconstruct the business logic before any rebuild begins. That process takes longer and costs more, but it produces the same result: a documented understanding of what the system does before any 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, ActiveX controls, and the Crystal Reports versions that shipped alongside VB6 are not unfamiliar territory for PCG.

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, not guesses.

What does a VB6 migration cost?

PCG does not quote VB6 migrations without an audit. The range for a complete migration, including the audit, rebuild, and data migration through training, runs from $15,000 for a straightforward single-module application to $40,000 or more for complex multi-module systems with significant undocumented logic. That range reflects 31 years of doing this work, not an estimate built from a sales conversation.

The audit engagement itself costs $2,500 and 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 at all, 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. Every calculation that 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, inconsistent data types, and records that accumulated formatting quirks over decades of manual entry. 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, not a copy of whatever the old system accumulated.

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.