How Long Will VB6 Apps Keep Running? — Runtime Support Status and a Practical Path to .NET Migration

“How long will this VB6 system keep running?” — that’s one of the questions we hear most often in consultations about legacy systems.

The answer is surprisingly clear-cut: Microsoft has published an official support policy. But its content is asymmetric — “the runtime will keep working for a while, but there’s no development backing left.” Without understanding that asymmetry correctly, you end up swinging between two extremes: “it still works, so we’re fine” and “we need to rebuild everything right now.”

On this blog, “VB6 / Access Legacy Business Apps — A Decision Table for Keep, Wrap, or Replace” laid out how to decide what to do with your VB6 assets. This article picks up where that one left off: once you’ve decided to replace (migrate) — or as you’re deciding — it digs into how to actually carry out a VB6-to-.NET migration.

1. The Bottom Line First

• Support for the VB6 IDE (development environment) ended on April 8, 2008. There is no longer any supported way to create or maintain VB6 apps, and Microsoft strongly recommends replacing them with modern technology.¹
• On the other hand, the VB6 runtime is supported “for as long as the Windows version it ships with is supported.” The list of covered OS versions includes Windows 11, Windows 10, and Windows Server 2025, and the goal is for existing apps to just keep working (“It Just Works”).² In other words, the answer to “how long will it run” is: for execution alone, as long as Windows itself is supported.
• That support, however, is limited to addressing serious regressions and critical security issues in existing apps. The runtime is also 32-bit only, and on 64-bit Windows it is only supported inside the WOW64 environment.²
• The real risk isn’t “it stops running” — it’s that you lose the ability to fix it. Getting and keeping the IDE grows harder every year, vendor support for the OCX controls you depend on lapses, and the people who can still write VB6 retire or move on. All three of these progress independently of how long Windows itself stays supported.
• There are three general approaches to migration: full rewrite, automated conversion, and staged migration. The first thing to decide isn’t which approach — it’s the inventory. Grasp the volume of screens, external integrations, OCX controls, and API declarations before choosing an approach.
• For the migration target language, C# is recommended for anything newly written. Microsoft has officially stated that VB.NET (Visual Basic) is on a stable-design track, with no new syntax and no extension into new workloads.³

2. The Precise Answer to “How Long Will It Run” — Reading the Support Policy

Microsoft’s VB6 support policy explains VB6 in terms of three components.²

The list of covered OS versions explicitly marks Windows 11, Windows 10, and Windows Server 2012 through 2025 as “runtime: supported” and “IDE: not supported.”²

There are three key points to reading this correctly.

First, runtime support is entirely subordinate to the Windows lifecycle. There is no independent date called the “VB6 runtime end-of-support date” — the end of support for whichever Windows version you’re running on is the deadline, full stop.

Second, the substance of that support is closer to a guarantee that things “keep working” than anything else. What gets addressed is limited to serious regressions (where an OS update breaks an existing app) and critical security issues — it does not include individual investigations or feature improvements.²

Third, VB6 apps can only ever live on as 32-bit processes. The runtime is 32-bit only, and on 64-bit OSes it is only supported inside the WOW64 emulation environment.² The moment you need to interoperate with a 64-bit-only DLL or SDK, a single process can no longer get the job done on its own. We covered how to work around this wall in “A COM Bridge Case Study: Calling a 64-bit DLL from a 32-bit App”.

3. “Running” and “Maintainable” Are Different Problems

Read the support policy on its own and it can sound like “there’s no rush.” In practice, though, the development and maintenance environment breaks down well before the runtime environment does.

• You can’t get hold of the IDE. The VB6 IDE isn’t supported on current OSes, and maintaining an official way to obtain and install it gets harder every year. It’s not unusual to find a company where “there’s exactly one machine in the building that can still fix this.”
• Vendor support for third-party OCX controls has lapsed. The support policy itself states plainly that third-party controls are the vendor’s responsibility.² It’s common for grid and reporting OCX controls to already be unobtainable, and the decision framework we laid out in “How to Handle ActiveX / OCX Today” applies directly here.
• The people who can write it disappear. This isn’t a language-spec problem, it’s a people problem. Almost no new engineers are learning VB6, so the number of people who can maintain it only ever goes down.
• Surrounding requirements keep hitting the 32-bit wall. New device SDKs, authentication libraries, and cloud integrations increasingly assume 64-bit and .NET, and the requirements you can’t pull directly into a VB6 process keep piling up.

In other words, “how long will it run” is only half the problem. The other half is: “when the next fix is needed, will you still have the people and environment left to make it?” Migration plans need to be drawn up not after something breaks, but while the people and environment capable of fixing things are still around.

4. A Decision Table for Migration Approaches

Even once you’ve decided to replace the system, there’s a range of ways to go about it. Here’s a rundown of the main approaches.

Which one to choose isn’t determined by lines of code alone. Microsoft itself, alongside its official guides, points users toward upgrade and migration partners (including migration-tool vendors) for the move¹, so mechanical conversion is a real, viable option. Regardless of which approach you pick, though, the inventory in the next chapter is a common prerequisite.

Note that the practical side of choosing “keep as-is + document” — pinning the runtime environment, backups, and how to accept the risk — is covered in the previous VB6 / Access article.

5. Pre-Migration Inventory — What to Investigate Before Touching Code

The accuracy of your estimate and your choice of approach are both determined by the accuracy of your inventory. At a minimum, list out the following.

1. A list of screens and reports — the number of forms, which screens are actually used (migrating unused screens is wasted effort), the types of reports and where they output to (direct-to-printer, or via Excel)
2. A list of external integrations — which of ADO/DAO/RDO is used for the database and what it connects to, file I/O, serial/socket communication, calls to other systems
3. A list of OCX / ActiveX / COM references — you can extract these mechanically from the references in the project file (.vbp). Whether each component is still obtainable, and whether alternatives exist, feeds directly into choosing an approach
4. A list of Win32 API declarations (Declare statements) — classify each by what the API is used for (printing, INI file read/write, window manipulation, and so on), and whether it can be replaced with a standard .NET feature
5. Business rules that exist only in the code — rounding behavior, cutoff dates, per-partner exceptions, and the like. The spots where “nobody knows why it’s written this way” are exactly where post-migration bugs tend to breed
6. Whether you have a way to test — what you’ll compare the migrated behavior against to confirm correctness. In most cases, cross-checking against the old system’s output (reports, CSVs, database contents) is the most practical verification method

This inventory isn’t wasted even if you don’t end up choosing a full rewrite. In fact, it’s normal for the inventory results to reveal an angle for staged migration — “we thought this needed a full rewrite, but actually the core logic can be pushed to the database side,” or “migrating just these ten screens first clears the 64-bit wall.”

6. Major Incompatibilities Between VB6 and .NET

VB6 and VB.NET/C# are further apart than their names suggest. Whether you go with mechanical conversion or a manual rewrite, the following differences will always demand design decisions.

What matters here is not letting the sheer volume of incompatibilities push you into treating full rewrite as the only option. On the contrary, the very fact that the left-hand side (VB6) of this table is still running correctly today is the best specification you’ll have for the migration. Running the old system in parallel as a “living spec” and cross-checking outputs as you go is, in practice, the most reliable way forward.

7. Practical Patterns for Staged Migration

When migrating without stopping the business, how old and new coexist becomes the crux of the matter. Here are three representative patterns.

7.1 Migrate the Data Layer First

In this setup, you move the VB6 app’s data from an Access file or a proprietary format to something like SQL Server first, and keep the VB6 side running by simply switching its connection target. Once the data has been modernized first, you can add new screens (on the .NET side) incrementally, all pointing at the same database. For the concrete steps involved with Access, see the upsizing chapter of the previous article.

7.2 Build New Features and Screens in .NET, Connected via COM Interop

This is a setup where the existing VB6 screens stay as they are, and new features are built in .NET to coexist alongside them. There are two directions this can go.

• Call .NET-side components from VB6: Expose a .NET class as COM, and VB6 can reference it as an ordinary COM component. We explained how to expose it in a typed way even on .NET 8 and later in “Calling a .NET 8 DLL from VBA with Types — dscom and the TLB”; the same idea applies when the caller is VB6 instead of VBA.
• Call VB6-side assets from .NET: An ActiveX DLL built in VB6 can be referenced from .NET via COM interop. This is useful when you want to keep the existing logic intact as a block and modernize only the screens to .NET first. The 32-bit constraint still remains, though, so treat this as a bridge for the migration period rather than a permanent solution.

7.3 Separate Processes and Integrate Between Them

Housing old and new in the same process via COM interop runs into constraints around bitness (32-bit/64-bit) and shared failure blast radius. When you need new 64-bit functionality, or want to isolate failures between old and new, split them into separate processes and integrate via files, named pipes, localhost communication, and the like. We’ve summarized the options for inter-process integration in “A Decision Table for Windows IPC”, and a concrete 32-bit→64-bit bridge example in the “COM Bridge Case Study”.

The principle common to every pattern is this: consolidate the boundary between old and new into a single place, and fix the format of the data that crosses it. If boundaries multiply piecemeal by screen or by feature, the cost of the coexistence period eats up whatever benefit the migration was supposed to deliver.

8. The Migration Target Language — C# or VB.NET?

It’s tempting to assume “coming from VB6, VB.NET is the natural choice,” but given Microsoft’s current language strategy, it isn’t that simple.

The official language strategy positions Visual Basic (VB.NET) as “a language that stays approachable and familiar by keeping a stable design,” and states explicitly that, as a rule, new features are consumption-only, no new syntax will be added, and it will not be extended into new workloads. At the same time, investment in core scenarios such as Windows Forms and libraries, and improvements to the development experience in Visual Studio, are said to continue.³

Read from a migration standpoint, that comes out as follows.

• Even if you choose VB.NET, existing scenarios (WinForms business apps) will keep working just fine for the foreseeable future. For teams with many VB6-experienced people, where the syntactic closeness lowers the learning cost, it’s a reasonable choice.
• That said, C# is recommended as the foundation for anything newly written from here on. Its language and ecosystem keep evolving, and the supply of samples, libraries, and talent is concentrated on C#. It’s a choice made so you don’t repeat the “no one left who can maintain VB6” problem ten years from now as “no one left who can maintain VB.NET.”
• As a middle-ground option, you can also receive the conversion tool’s output in VB.NET while writing new development in C#. In .NET, assemblies from both languages can reference each other, so mixing languages in itself is not an obstacle.

For your choice of UI framework (WinForms / WPF / WinUI), see “A Decision Table for WinForms, WPF, and WinUI”; for what to check when migrating directly to current .NET rather than .NET Framework, see “A Pre-Migration Checklist for .NET Framework → .NET”. Barring some constraint from a referenced library, there’s no good reason to deliberately adopt .NET Framework 4.8 as a new target when migrating away from VB6.

9. Summary

• The answer to “how long will VB6 run” is: the runtime is supported for as long as Windows itself is supported (Windows 11 included). But the IDE’s support ended back in 2008, so there’s already no official backing for rebuilding or fixing it — an asymmetric state of affairs.²¹
• The real deadline isn’t set by the OS — it’s set by whether the environment and people needed to fix things are still around. Draw up your migration plan not after something breaks, but while the old system can still be used as a “living spec.”
• There are three approaches: full rewrite, automated conversion, and staged migration. Before choosing one, take inventory of your screens, external integrations, OCX controls, API declarations, and business rules that exist only in the code.
• For migrations that can’t stop the business, use data-layer-first, COM interop, or process separation to let old and new coexist — and consolidate the boundary into a single place.
• For anything newly written, C# is recommended. VB.NET’s stable-track status is official policy³, and C# has the advantage as the foundation for long-term maintenance.

Related Articles

• VB6 / Access Legacy Business Apps — A Decision Table for Keep, Wrap, or Replace
• How to Handle ActiveX / OCX Today — A Keep / Wrap / Replace Decision Table
• A COM Bridge Case Study: Calling a 64-bit DLL from a 32-bit App
• Calling a .NET 8 DLL from VBA with Types — dscom and the TLB
• A Pre-Migration Checklist for .NET Framework → .NET
• A Decision Table for WinForms, WPF, and WinUI
• What Is VBA? — Constraints, Future Outlook, and Realistic Migration Patterns

Related Consulting Areas

KomuraSoft LLC handles inventory and migration-strategy planning for existing assets including VB6, the design and implementation of coexistence architectures for old and new systems via COM bridges and process separation, and staged replacement projects moving to .NET.

• Legacy Asset Reuse & Migration Support
• Maintenance and Enhancement of Existing Windows Software
• Windows App Development
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Will VB6 apps still run on Windows 11?

Yes, they are within the supported scope. Under Microsoft's support policy, the VB6 runtime (msvbvm60.dll and friends) remains supported for as long as the Windows version it ships with is supported, and the list of covered OS versions includes Windows 11, Windows 10, and Windows Server 2025. That support, however, is limited to addressing serious regressions and critical security issues in existing apps. The VB6 runtime is also 32-bit only, and on 64-bit Windows it is supported only inside the WOW64 32-bit compatibility environment.

Can a VB6-to-.NET migration be completed with an automated conversion tool alone?

You should assume it cannot. Conversion tools can reduce the manual effort of rewriting screen definitions and simple logic, but things like On Error-based error handling, code that depends on the Variant type or default properties, ActiveX controls, and Win32 API declarations require human design decisions and fixes. Rather than putting the tool's raw output straight into production, you need to estimate the whole project including the 'human finishing work after conversion,' and decide in advance how you will verify the converted result — for example through parallel operation or output comparison.

Should the migration target be VB.NET or C#?

For anything newly written, C# is recommended. Microsoft's language strategy positions Visual Basic (VB.NET) as a language that keeps a stable design, explicitly stating that no new syntax will be added and it will not be extended to new workloads. Investment in existing scenarios such as Windows Forms continues, so VB.NET does not become unusable, but as the foundation for code you'll maintain for the next decade, C# — where both the language and its ecosystem keep evolving — has the advantage when it comes to securing talent. Teams with many VB6-experienced developers may reasonably choose to go through VB.NET given how close its syntax is.

Before a full rewrite, what should we do first?

You should take inventory before writing a single line of code. Specifically: a list of screens and reports, a list of external integrations (databases, files, serial communication, other systems), a list of the OCX/ActiveX controls and COM components referenced, a list of Win32 API declarations (Declare statements), and a survey of business rules that exist only in the code. The results of this inventory very often reveal that a staged migration — carving out only part of the system, or moving the data layer first — is more realistic than a full rewrite.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.