Support status · Visual Basic 6
Is Visual Basic 6 still supported?
The runtime is supported. The development environment has not been since 2008.
Microsoft supports the core VB6 runtime for the full lifetime of the supported Windows versions it ships with, which is why your application still starts every morning and why nobody has been forced to act. The VB6 IDE and Visual Studio 6.0 have been out of support since 8 April 2008. So the application runs, and changing it requires a development environment that has been unsupported since 2008, on a machine you are keeping alive deliberately. Being able to run something is not the same as being able to maintain it.
- VB6 runtime
- Supported with the Windows it ships with
- VB6 and Visual Studio 6.0 IDE
- Unsupported since 8 April 2008
- Language and tooling
- No development, no fixes
- Runtime guarantee
- Compatibility, not a support commitment for the tooling
Source: Microsoft: support statement for Visual Basic 6.0 on Windows. Check it. We would rather you did.
- Microsoft's own statement, linked
- No email needed to read it
- Leaving it alone is a real answer
What that actually means
The position most estates are in
The development environment is a machine, not a product
You can still run the application. Building a change to it means keeping a specific old Windows image alive with a specific old IDE on it, and that machine is usually one disk failure away from gone, along with the only build that is known to produce a working binary.
The runtime promise covers the runtime, and nothing else
The core runtime ships with Windows and is supported with it. That commitment does not extend to the language, the IDE, the controls or any third-party OCX in your application, and it does not oblige anyone to carry it forward beyond the Windows releases it is already in.
The knowledge retired before the software did
VB6 expertise is now genuinely scarce. The people who understand your application are usually reachable as favours, then as contractors at scarcity rates, then not at all, and that sequence runs faster than most replacement plans.
Exposure
What breaks, how likely, what it costs
Stated generically here because it is generic until someone looks at your estate. These are the scenarios that actually land, in the columns your risk register already has.
| Scenario | Likelihood | Impact |
|---|---|---|
| The machine holding the VB6 IDE fails | A hardware question, so eventually yes | No further changes can be made to the application at all until it is rebuilt or recreated |
| A third-party OCX will not register on a newer Windows | Common on estate refreshes | The application blocks the desktop upgrade, or the upgrade blocks the application |
| A regulation or an integration forces a change | The usual trigger, and unpredictable | A change is required to software nobody can safely change, on a deadline set elsewhere |
| The last person who understands it leaves | Often already happened | The application becomes a black box that is trusted because it has always worked |
What we do about it
The work itself
What the application actually does, recovered
Forms, modules, class files and the COM components underneath, read at volume and written down as business rules a reader who has never opened VB6 can follow and check.
The dependency surface, mapped
COM registrations, ActiveX controls, third-party OCXs and database bindings. This is the part that makes VB6 projects overrun, and it is knowable in advance rather than discovered in month four.
Behaviour pinned before anything moves
Characterisation tests against the existing application first, so the replacement is checked against what the software really does rather than what the documentation claims it does.
Moved in pieces, never in one jump
Screen by screen, with both versions runnable side by side and each step independently revertible. No date on which everyone switches and hopes.
What decides the cost
The three things worth knowing before anyone quotes
- OCX inventory
- Third-party controls are the first thing we would inventory, because they are the hardest part to reproduce and the easiest to miscount when quoting. Some get replaced, some wrapped, some turn out to be dead.
- Build reproducibility
- Whether anyone can still produce a working binary from the source, on a machine that exists. Surprisingly often the answer is no, and that changes the plan.
- Desktop or not
- Whether the replacement still needs to be a desktop application in five years. This decides the destination more than the source language does.
The engagement
How the work runs
You tell us what you know
Roughly how big, roughly how old, and what would hurt most if it stopped.
We read the code
Inventory of forms, modules and dependencies, plus how much of it is provably unreachable.
One screen goes first
A real screen, rebuilt and in use, running beside the VB6 application. That is where throughput becomes a measured number.
The rest follows in that order
Measured against the first screen, sequenced so the work the business depends on most stops depending on the old build machine earliest.
Questions
Frequently asked
Is Visual Basic 6 still supported?
Partly, and the distinction matters. Microsoft supports the core VB6 runtime for the full lifetime of the supported Windows versions it ships in, so your compiled application keeps running and keeps being supported in that narrow sense. The VB6 IDE and Visual Studio 6.0 have been out of support since 8 April 2008. You can run it. You cannot maintain it with anything supported.
Our VB6 app works perfectly. Why touch it?
If it works, is not internet-facing, and genuinely never needs changing, deciding to leave it alone can be entirely rational and we will say so. The problem is almost never that it stops working. It is that a regulation, an integration or a supplier eventually forces a change, and by then nobody can safely make one, and that moment arrives with a deadline attached that you did not choose.
Should we move to VB.NET or something else entirely?
VB.NET is the shortest hop and preserves the most familiarity, but it inherits a desktop-application shape you may no longer want, and it is a smaller pool of developers each year. The honest answer depends on whether the application needs to be a desktop app at all in five years. If it does, .NET is a reasonable destination. If it does not, a web application removes the deployment problem that VB6 estates usually also have.
How do you handle the COM and ActiveX dependencies?
By finding all of them first. Registered components, third-party OCXs and anything loaded dynamically get inventoried before a plan is written, because unknown dependencies are a well-known reason VB6 migrations run over. After that it is case by case: some get replaced, some get wrapped, and some turn out to be dead.
Nobody here can build it any more. Is it too late?
No, and it is a more common starting point than you would expect. A binary that runs is itself a specification: behaviour can be observed, recorded and pinned with tests even where the source cannot be compiled. It is more work than a clean build, and it is the situation the comprehension-first approach handles best, because it never assumed the source was trustworthy in the first place.
Will an unsupported IDE fail a Cyber Essentials assessment?
A development tool on a developer machine is usually in scope, and unsupported software in scope is an automatic failure rather than a finding to explain. The runtime on user machines is a different question, since it is supported with Windows. Worth confirming with your assessor rather than assuming, because the two halves of the VB6 answer land differently.
Have you migrated VB6 specifically?
Our deepest delivery experience is ColdFusion. The method, which is to recover the behaviour, pin it with tests, port incrementally and verify each step, is not language-specific, and reading unfamiliar code at volume is exactly what makes it portable. We would rather tell you that plainly than show you a case study we do not have.
Talk to someone who would read the code
A name, an email, and three optional questions. What comes back is a reply from the engineer who would read the code, and it is either a conversation about replacing it or an honest reason why we are not the right people.
Other platforms