DECISION GUIDE

Who still supports VB6 in 2026:
Microsoft keeps the runtime running. Everything else is on you.

BY THOMAS JAEGER · PUBLISHED SEP 5, 2026

Visual Basic 6 shipped in 1998; the environment that builds it left support in 2008. The applications did not leave production with it. Microsoft keeps the runtime alive; nobody keeps the IDE, the third-party controls, or your own code alive. The question is not whether VB6 is supported, but who is supporting yours.

The short answer. Microsoft supports the VB6 runtime for as long as the Windows version it ships in is supported, and nothing else. The IDE, third-party controls, and your own code are supported by whoever you hire. Treat “support” as engineering deliverables, not a retainer, and decide whether that money should maintain the application or replace it.

What Microsoft still supports, and what it does not.

Microsoft’s support statement for Visual Basic 6.0 on Windows is short. The runtime, msvbvm60.dll and the base libraries an application needs to execute, ships inside Windows and is supported for the support lifetime of that Windows version. Windows 10, Windows 11, and current Windows Server releases are on the list; the stated goal is “It Just Works” compatibility for existing applications.

The IDE is different. The Visual Basic 6.0 and Visual Studio 6.0 environments have been unsupported since April 8, 2008: no fixes, security or otherwise, and in Microsoft’s words there is no supported method to create or maintain Visual Basic 6 applications. Even the runtime’s support bar is narrow: serious regressions and critical security issues, nothing more.

Two more lines matter. The runtime is 32-bit only, so on 64-bit Windows a VB6 application runs under WOW64 and cannot load 64-bit components. And third-party OCX and ActiveX controls are explicitly outside Microsoft’s support; the original vendor is the only source of help, if it still exists.

Why the developer pool is shrinking, and what that does to cost and risk.

Nobody learns VB6 as a first language any more. The developers who know it well learned it in the late 1990s or early 2000s, and each year some retire, move into management, or decline VB6 work. The population is not being replenished.

A shrinking pool changes the economics three ways. Rates rise, because the remaining specialists can choose their work. Lead times lengthen, because the person you need is booked. And the risk moves from “expensive” to “unavailable”: the failure mode is not a large invoice but a defect nobody is available to fix in time.

It also changes what you are buying. VB6 competence today is less about the language, which is small, and more about the platform: COM registration, the runtime extended files, particular third-party controls, Jet and DAO, and how they behave under UAC, DPI scaling, and 64-bit Windows. That knowledge is thinly documented and lives in people.

The options, with honest trade-offs.

There are five places to get VB6 work done. None is wrong; each has a failure mode to know about first.

In-house
Lowest hourly cost and deepest knowledge of the application, if the person exists. The risk is concentration: one departure and the ability to build it is gone, so plan a documented handover and a trained second person.
Freelancers and contractors
Plentiful, variable in quality, and hard to verify, because VB6 skill is not certifiable. Good for bounded tasks with a clear acceptance test; weak where continuity matters.
Specialist firms
Firms that maintain and modernize legacy Windows applications for a living. Higher rates than freelancers, offset by continuity, process, and a written record. Prefer one that will say in writing when the right answer is to leave the code alone.
Conversion tool vendors
Vendors of VB6-to-.NET converters also sell migration services. Right when conversion is already the chosen path and the code is conventional; wrong for ongoing maintenance, because the incentive is the conversion, not the upkeep.
Offshore teams
Lower rates and sometimes a larger VB6 bench. The costs are coordination, access to your environment, control of source and data, and confirming that the team you interviewed is the team doing the work; confidentiality obligations may rule it out.

What “support” should include.

A phone number and an hourly rate are not support. Whoever maintains a VB6 application should be able to show five things; if not, producing them is the first job.

Source control with a known-good tag
Every source, form, and resource file in a repository, tagged to match the binary in production. A project that lives on one workstation is a rumor, not an asset.
A reproducible build
A documented machine, physical or virtual, with the IDE, the exact service pack, every referenced OCX and type library at the right version, and a written procedure that reproduces the deployed binary.
A component and license inventory
Every third-party control and library: version, vendor, whether the vendor still exists, whether you hold the license and source, and whether a 64-bit or .NET equivalent exists.
Documented deployment
Which runtime extended files the installer carries, how controls are registered, which registry keys and folders the application expects, and how a clean Windows 11 machine gets to a working install.
A bus-factor plan
A named second person who has built and deployed the application from the repository, and a written escalation path if the first is unavailable. “Call the vendor” only counts if the vendor is under contract.

When to keep supporting, and when to migrate.

Keeping a VB6 application is a legitimate decision, and the right one more often than modernization vendors admit. The test is the one in our guide on when not to modernize: the application is stable, changes rarely, runs on a supported platform, and costs a known, bounded amount to keep.

The case for migrating is built from specific facts, not the age of the language: a third-party control with no vendor and no 64-bit path; a dependency on 32-bit Office, ODBC, or MAPI that a planned desktop upgrade will remove; a backlog that keeps growing because every change is slow and risky; a bus factor of one. One of those is a reason to look; two or three is a reason to act.

Windows 11 forces neither decision; the runtime is supported there. It does expose third-party controls, installers, and DPI assumptions that were already fragile, which our guide on VB6 and Windows 11 walks through. Decide on the facts of your application, and put a date on the decision.

How to evaluate a vendor.

The same questions separate people who can support a VB6 application from people who can talk about one. Ask them in writing.

Can you build it from source on a clean machine?
Ask for the procedure, not the promise. A competent vendor asks for your component inventory first.
What happens to our source and data?
Where it is held, who can see it, whether it leaves your infrastructure, and what is returned or destroyed at the end. Vagueness disqualifies.
Who does the work, and who is the backup?
Names, not a team page, and what happens when that person is unavailable for a month.
How do you report progress, and against what budget?
Weekly written status against a fixed or not-to-exceed budget is reasonable; an open-ended retainer with no reporting cannot be bounded.
When would you tell us to stop paying you?
A vendor with both a maintenance and a migration business has an incentive either way. Ask when they would recommend leaving the application alone, and when replacing it.
Will you start with a read-only assessment?
A fixed-scope, read-only review of source, components, data, and deployment, ending in a written report, tests both the application and the vendor. Ours is the Legacy Software Assessment.

Where each option fits.

OptionStrengthsRisksFits when
In-house developerLowest hourly cost; deepest knowledge of the applicationNo second builder; no cover for departure; skills go staleThe application changes often and a second person can be trained
Freelancer or contractorFast to engage; pay per taskHard to verify; little continuity; source leaves your controlBounded fixes with a clear acceptance test
Specialist firmContinuity, process, written records, a migration path if neededHigher rate; every ticket can become a migration pitchBusiness-critical application; one accountable party wanted
Conversion tool vendorDeep VB6-to-.NET translation knowledge; fast compiling baselineIncentive is the conversion; output compiles before it is maintainableConversion is already the chosen path
Offshore teamLower rates; sometimes a larger VB6 benchCoordination, access control, confidentiality, verifying who does the workWell-specified work, low-sensitivity data, a contract covering source handling

Common questions

Does Microsoft still support VB6 in 2026?

Partly. The runtime ships in Windows 10, Windows 11, and current Windows Server releases and is supported for the lifetime of each, limited to serious regressions and critical security issues. The IDE has been unsupported since April 8, 2008, and third-party ActiveX controls are not covered.

Will a VB6 application keep running on Windows 11?

Usually, because the runtime is part of the operating system and runs under WOW64. What breaks is around it: third-party OCX controls, unsigned installers, DPI scaling, and 32-bit dependencies on 64-bit Office or ODBC. Our guide on VB6 and Windows 11 covers each.

Where do you find VB6 developers for hire?

Freelance marketplaces, specialist legacy firms, conversion tool vendors, and offshore teams, in roughly increasing order of commitment. Skill is hard to certify, so test it: have a candidate build your application from source on a clean machine before signing anything beyond one task.

How much does VB6 maintenance cost?

It depends on the size of the code, the state of its build and deployment, and its third-party components, so we do not publish maintenance rates. Our published range for a Visual Basic migration project is $15,000–$250,000; the assessment fixes the figure.

Is running VB6 a security risk?

The runtime receives critical security fixes through Windows servicing. Nothing else does: the IDE, third-party controls, and your own code get no fixes from Microsoft. The practical risks are unsigned installers, controls with unpatched vulnerabilities, and code nobody has reviewed in years.

Should we migrate VB6 to .NET or keep supporting it?

Keep it if it is stable, changes rarely, and its cost is bounded. Migrate when a specific fact forces it: a control with no vendor, a 32-bit dependency about to disappear, or a growing backlog. A read-only assessment supplies the verified facts either way.

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.