Tag: legacy application modernization

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.

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

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.

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

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.