// Not Sure Where to Start?
Visual Basic Programming
Last updated: April 2026
If your business is running a critical operation on a Visual Basic 6 application in 2026, PCG can repair it, extend it, or migrate it to .NET. VB6 reached end-of-support from Microsoft in 2008. The runtime still works on Windows 11, but there are no security patches, no 64-bit support, and a shrinking pool of developers who can actually read the code. PCG was building production applications in Visual Basic 5 and 6 for major corporations before VB6 was considered legacy.1
What is Visual Basic 6 and why are businesses still running it in 2026?
Visual Basic was a Microsoft programming language first released in 1991. It allowed developers to build Windows applications quickly using a visual drag-and-drop interface combined with Basic-derived code. For over a decade it was one of the most widely used development platforms for business applications: inventory systems, payroll calculators, data entry tools, reporting platforms, and operational dashboards across manufacturing, healthcare, finance, and dozens of other industries.
Microsoft ended mainstream support for VB6 in 2005 and extended support in 2008. The VB6 runtime was included in Windows through Windows 10 and continues to function on Windows 11 for backward compatibility, but it receives no security updates, has no 64-bit support, and cannot call modern Windows APIs directly. Organizations still running VB6 in 2026 are typically there for one of two reasons: the cost and disruption of migration has been deferred repeatedly, or the original developer is gone and nobody on the current team can read the code.
In 2026, a VB6 application running on Windows 11 is an unpatched attack surface. Any vulnerability in the VB6 runtime or in the application code itself will never receive a fix from Microsoft. For organizations with regulatory compliance requirements, this is not a theoretical risk. It is a documented exposure that auditors are increasingly flagging.
What is the full history of Visual Basic versions PCG works with?
| Version | Released | Microsoft Support Status | PCG Capability |
|---|---|---|---|
| Visual Basic 1.0 | 1991 | End of life | Can read and migrate legacy VB1 code |
| Visual Basic 2.0 / 3.0 | 1992-1993 | End of life | Can read and migrate legacy VB2/VB3 code |
| Visual Basic 4.0 | 1995 | End of life | Can read, repair, and migrate VB4 code |
| Visual Basic 5.0 | 1997 | End of life | Active development history. PCG built production VB5 applications for enterprise clients |
| Visual Basic 6.0 | 1998 | End of support 2008. Runtime only. | Primary legacy VB service. Repair, extension, and .NET migration |
| VBA (Access and Excel) | 1993-present | Active. Supported by Microsoft. | New VBA development, repair, automation, and migration to .NET |
| VB.NET (Visual Basic .NET) | 2002-present | Active. Current Microsoft support. | New development and migration target for VB6 applications |
What are the signs your VB6 application is approaching a failure point?
VB6 applications do not usually fail catastrophically without warning. They degrade over time as the operating environment changes around them. These are the most common signals that a VB6 application is approaching the point where a Windows update, a hardware change, or a staff departure will make it unrecoverable.
The application breaks after every major Windows update
VB6 applications rely on COM components and Windows runtime libraries that Microsoft no longer maintains for compatibility. Each major Windows update is a potential breakage event. If your IT team is already on a first-name basis with the process of rolling back Windows updates to keep a VB6 application running, the clock is counting down to an update that cannot be rolled back.
The developer who built it retired or left, and nobody else can maintain it
VB6 developers who were active in 1998 are now in their 60s and 70s. Many have retired. The pool of developers who can read VB6 code at a professional level and debug it under pressure is small and shrinking. If the person who built your VB6 application is no longer available and your IT team cannot modify the code, you are running a production system with no maintenance path. PCG can read that code.
The application cannot run on a new workstation without special configuration
VB6 applications depend on specific runtime files and registered COM components that must be present on every machine that runs the application. Modern Windows workstations do not include these by default. When a new employee gets a new workstation and IT cannot get the VB6 application to run on it without an hour of manual configuration, that is a deployment problem that only gets worse as the organization grows.
The application cannot connect to modern systems without brittle workarounds
VB6 was built before REST APIs existed as a standard. Connecting a VB6 application to a modern cloud platform, a web service, or a SQL Server instance running current security protocols requires workarounds that break with system updates. If your VB6 application's integration with other systems requires regular manual intervention to keep working, that integration debt compounds every month.
A security audit has flagged the VB6 application as an unpatched exposure
Organizations in regulated industries are increasingly receiving audit findings that specifically identify VB6 applications as unpatched software running on their infrastructure. VB6 has known vulnerabilities that will never receive security patches from Microsoft. For organizations subject to HIPAA, environmental regulations, financial compliance, or government contractor requirements, an unpatched VB6 application on a production system is a documented compliance gap.
What are the options for a VB6 application in 2026, and what does each actually involve?
| Option | What It Involves | When It Makes Sense | Risk Level |
|---|---|---|---|
| Emergency repair only | Fix the specific failure without touching the rest of the application. Restore operation without migration commitment. | Application failed unexpectedly and business cannot wait for a migration. Buys time while migration is planned. | Medium. Problem recurs. |
| Extend and stabilize | Add new functionality or integrate with modern systems while keeping the VB6 core. Typically requires a wrapper layer around the VB6 application. | Application is stable and not approaching immediate failure. New requirements cannot wait for a full migration. | Medium-high. Technical debt grows. |
| Migrate to VB.NET | Rewrite the application in Visual Basic .NET. Language syntax is similar which reduces relearning for VB-familiar developers. Full Microsoft support and modern Windows integration. | Organization prefers to stay in the VB language family. Developers maintaining the system know VB syntax. | Low. Fully supported platform. |
| Migrate to C# .NET | Rewrite the application in C# on the .NET Core platform. Industry-standard for Windows application development. Wider developer pool for ongoing maintenance. | Organization wants the largest possible developer pool for future maintenance. PCG's primary recommendation for most VB6 migrations. | Low. Largest long-term support base. |
| Rebuild as web application | Rewrite the application as a browser-based .NET Core web application. Eliminates Windows-only limitation. Multi-location access without deployment overhead. | Application needs to be accessible from multiple locations or devices. Current Windows-only limitation is a business constraint. | Low. Adds deployment flexibility. |
What does PCG's VB6 migration process actually involve?
The hardest part of a VB6 migration is not the rewriting. It is extracting the business logic that is embedded in 25 years of code, patches, and undocumented modifications. Most VB6 applications in production today were written by one person, modified by several others over the following decade, and have not had a code review since the original developer left. PCG reads what is actually there before writing a line of replacement code.
1
Code Audit and Business Logic Extraction
PCG reads the complete VB6 codebase: every form, every module, every class, every database interaction. The audit maps every business rule implemented in code, every calculation formula, every workflow sequence, and every external dependency the application has. Undocumented logic that has been accumulating since 1998 is identified and documented before any migration decisions are made. This is the phase that most VB6 migration attempts skip, and the reason most of them fail.
2
Architecture Decision and Migration Plan
PCG recommends the target platform based on the audit findings, your organization's maintenance capacity, and your operational requirements. Most VB6 applications migrate cleanly to C# .NET Core with a SQL Server back-end. Some are better served by a web application architecture. PCG presents the options with honest cost and timeline estimates for each before any commitment is made.
3
Parallel Build and Validation
PCG builds the replacement application in parallel with the live VB6 system. Your team continues running on the VB6 application throughout the build. The new application runs against your actual operational data during the validation period, producing outputs that your team compares directly against the VB6 application they trust. No cutover is made while any functional discrepancy exists between the old and new systems.
4
Data Migration and Cutover
Historical data from the VB6 application's database is cleaned, mapped to the new schema, and migrated with full validation and post-migration reconciliation. The VB6 application remains accessible in read-only mode during the post-cutover verification period. PCG delivers the completed application with full source code, technical documentation, and staff training. The VB6 application is retired only after the new system has been confirmed in production.
PCG was building production Visual Basic 5 and 6 applications for major corporations before VB6 was considered legacy. That means PCG's developers have first-hand knowledge of what VB6 applications were doing when they were written, how they were structured by the developers of that era, and what the common failure patterns are in applications that have been maintained by different hands over 25 years.
When a VB6 application arrives at PCG for migration, the audit phase is faster and more complete than it would be at a firm that learned VB6 from reading about it. The business logic extraction is more accurate. The migration is less likely to miss something that mattered. PCG was founded in 1995, the same year VB4 was released. That timeline is not a coincidence.
What are the specific risks of keeping a VB6 application in production in 2026?
- No security patches, ever. Microsoft ended all support for VB6 in 2008. Any vulnerability discovered in the VB6 runtime or in your application code will never receive a patch from Microsoft. For organizations subject to compliance requirements that mandate patched software, this is an unresolvable gap until the application is replaced.
- 32-bit only, on a 64-bit world. VB6 applications are 32-bit. Windows 11 runs them through a compatibility layer, but that layer is not guaranteed to persist in future Windows versions. Every major Windows release since Windows 8 has required Microsoft to make a deliberate decision to keep VB6 compatibility. That decision is not permanent.
- The developer pool is disappearing. VB6 developers who were mid-career in 1998 are now in their late 50s through 70s. The number of developers who can read and debug VB6 code under production pressure is declining every year. Waiting longer to migrate means finding someone qualified to do it will cost more and take longer.
- A single Windows update can make it permanently inoperable. Microsoft has broken VB6 COM dependencies in past Windows updates and patched them when organizations complained loudly enough. That feedback loop is weaker now. An update that breaks a VB6 runtime component may not get reversed.
- No integration with modern systems without brittle workarounds. REST APIs, OAuth authentication, TLS 1.3, modern SQL Server security protocols: VB6 cannot call these natively. Every integration with a modern system requires a compatibility layer that adds maintenance overhead and breaks when either connected system updates.
1 PCG VB5/VB6 development history documented from project records, 1995-2026. Enterprise VB5 and VB6 applications built for ExxonMobil, Nabisco, and other Fortune 500 clients during the platform's active development era.
2 Microsoft VB6 support timeline: mainstream support ended April 8, 2005; extended support ended March 31, 2008. VB6 runtime included in Windows for backward compatibility through current Windows 11 release as of April 2026.
Frequently Asked Questions
Yes. VB6 applications typically break after Windows updates due to COM component registration failures, missing runtime DLLs, or changes in Windows security policies that affect how VB6 accesses system resources. PCG diagnoses the specific cause of the failure and restores the application to working order. Emergency VB6 repairs are treated as priority engagements because a broken VB6 application in production typically means a business operation has stopped. Most VB6 emergency diagnoses are completed within one business day of first contact.
Simple VB6 applications with a focused feature set, clean code, and well-structured database typically migrate in eight to sixteen weeks. Complex applications with undocumented business logic, multiple external dependencies, decades of patches applied by different developers, and large data volumes typically run sixteen to thirty-two weeks. PCG provides a timeline estimate after the code audit, not before it. The audit is the only way to know what is actually in the codebase.
Yes. PCG's parallel validation methodology ensures the new application produces the same outputs as the VB6 application across every workflow your team uses before any cutover decision is made. Business rules, calculation logic, report formats, and workflow sequences are all verified against the VB6 application during the validation period. No cutover happens while any functional discrepancy exists. If the code audit reveals VB6 logic that was producing incorrect results, PCG flags it for your team's decision before the migration rather than carrying the error forward.
Yes. PCG reverse-engineers the business logic directly from the VB6 source code rather than from documentation. The code audit phase reads every form, module, and class in the application and maps what it does from the code itself. The absence of documentation extends the audit phase but does not prevent a complete and accurate migration. PCG produces the documentation during the audit as a deliverable of the engagement, so the migrated application has documentation the VB6 original never had.
Yes, with caveats. PCG can add functionality to a VB6 application when the addition does not require capabilities the VB6 runtime cannot support natively. New forms, new reports, additional database queries, and modifications to existing business logic are all feasible within VB6. Additions that require REST API calls, modern authentication protocols, 64-bit operations, or direct integration with current cloud platforms are not feasible in VB6 without a wrapper layer. PCG advises on which additions are practical within VB6 and which require migration as a prerequisite.
PCG migrates the complete historical data record from the VB6 application's database to the new system's database. Data quality issues accumulated over years of VB6 operation, including inconsistent formats, duplicate records, and referential integrity violations that VB6 never enforced, are identified during the migration and corrected before import. Post-migration reconciliation confirms that source and destination records match before the VB6 system is retired. The new system opens with a cleaner historical record than the VB6 database held.
Yes. PCG develops, repairs, and migrates VBA code in both Microsoft Access and Excel. VBA in Access and Excel is technically distinct from standalone VB6 but shares the same language syntax and many of the same failure patterns. PCG handles Access VBA for database automation and business logic, Excel VBA for workbook automation and reporting, and the migration of VBA-based systems to standalone .NET applications when the Access or Excel platform has been outgrown.