Does VB6 work on Windows 11?

Yes. Microsoft supports the VB6 runtime on Windows 11 for as long as Windows 11 itself is supported, under its 'It Just Works' compatibility statement. That support covers only serious regressions and critical security issues. VB6 apps run as 32-bit processes under WOW64, and Microsoft does not cover third-party OCX or ActiveX controls, so test each dependency before assuming the whole application is safe.

Is Visual Basic 6 still supported by Microsoft?

Partly. The VB6 runtime files are supported for the lifetime of supported Windows versions, limited to serious regressions and critical security issues. The VB6 IDE and Visual Studio 6.0 have been unsupported since 8 April 2008, so there is no supported way to edit or compile VB6 code. Microsoft strongly recommends replacing VB6 applications with modern technology.

Can VB6 be converted to C# automatically?

Mostly. Commercial converters such as GAPVelocity's VB6 AI Migrator aim for 90 to 95% automated conversion by the vendor's own figures, leaving 5 to 10% for engineers. That remainder holds the hardest code: global state, ActiveX controls and undocumented data access. The output also keeps the VB6 structure, so plan characterisation tests that prove the behaviour has not changed.

Should a VB6 application move to WinForms or the web?

WinForms on .NET 10 is usually the cheapest target for a desktop tool used by a few people on the office network, because the screens map closely. Choose a web front end when users work remotely, need browser or mobile access, or you want to stop managing desktop installs. Either way, move the business rules into a separate C# layer so the front end can change later.

How long does a VB6 to .NET migration take?

It depends on size, dependencies and how much of the behaviour is documented. GAPVelocity's 2026 demand report puts the median VB6 application scoped for modernisation at about 124,000 lines of code. Testing and user sign-off drive the calendar more than coding does. A two-week Blueprint on your own code gives you a fixed price and a timeline before you commit.

VB6 on Windows 11 in 2026: Support and Migration to .NET

Yes. VB6 applications still run on Windows 11, and Microsoft supports the VB6 runtime for as long as the Windows version underneath is supported. That support is limited to serious regressions and critical security issues. The VB6 development environment has been unsupported since 8 April 2008, so there is no supported way to change or rebuild the application, and Microsoft’s own advice is to replace it.

This article covers what Microsoft actually supports, where VB6 applications break in practice, and the four realistic ways out, with the trade-offs of each.

Does VB6 still run on Windows 11?

Microsoft’s Support Statement for Visual Basic 6.0 describes its goal as “It Just Works” compatibility for existing VB6 applications on supported Windows versions. The statement was last revised in December 2024. It lists Windows 11, Windows 10 and every current Windows Server release up to Windows Server 2025.

VB6 component	On Windows 11	What it means for you
Runtime files shipped in Windows (msvbvm60.dll and others)	Supported	Already present. Fixes are limited to serious regressions and critical security issues.
Runtime extended files (common controls such as mscomctl.ocx and comdlg32.ocx)	Supported	You must still redistribute them with your installer.
VB6 IDE	Not supported	No supported way to edit or compile the code.
Third-party OCX and ActiveX controls	Not covered	Microsoft refers you to the original vendor.

There are two caveats. First, VB6 runtime files are 32-bit only, and on 64-bit Windows they are supported only inside WOW64, the 32-bit compatibility layer. Windows 11 requires a 64-bit processor, so every Windows 11 machine runs your app that way. Second, Microsoft lists some runtime files as unsupported, including familiar ones such as threed32.ocx and tlbinf32.dll. If your app ships any of them, the compatibility promise does not cover that part.

Is the VB6 IDE still supported?

No. Microsoft ended support for the Visual Basic 6.0 and Visual Studio 6.0 IDEs on 8 April 2008. The same statement says the IDE was never offered in a 64-bit version, and the 32-bit IDE has never been supported on 64-bit Windows. Because there is no supported way to create or maintain VB6 applications, Microsoft “strongly recommends” replacing them with modern technology.

If your fallback is an old virtual machine with the IDE installed for emergency fixes, it works until the VM, the licence key or the person who knows how to build the installer disappears.

What are the real risks of keeping a VB6 application?

The support statement covers Microsoft’s files. Most of the risk sits in everything around them. These are the five areas I check first.

32-bit limits. A VB6 process cannot load 64-bit DLLs. When a database driver, printer SDK or Office integration becomes 64-bit only, the app stops working and there is no setting that fixes it.
COM, ActiveX and OCX dependencies. Grid, charting, barcode and reporting controls were usually bought from vendors who have since disappeared or stopped updating them. Microsoft does not support third-party controls, and you may no longer hold the design-time licences needed to rebuild.
Installers. Many VB6 apps depend on an old setup package that registers controls and needs local admin rights. A new laptop build or Windows image is where these usually break.
Knowledge loss. The source may be incomplete, and the one person who understood the business rules may be about to retire. In many VB6 apps the code is the only record of how pricing, costing or scheduling actually works.
Security. You cannot patch the compiler or the controls. An application you cannot rebuild is an application you cannot fix quickly, which is hard to defend in a customer security questionnaire. Look for SQL built by string concatenation and credentials in INI files while you are there.

GAPVelocity’s 2026 demand report makes the same point from the vendor side. A supported runtime, it says, does not restore support for an abandoned control or make the original development environment maintainable.

Why are companies migrating VB6 now?

The most detailed recent data comes from a vendor, so read it with that in mind. GAPVelocity AI, a migration company whose lineage runs through ArtinSoft and Mobilize.Net, published The State of Legacy Modernization Demand 2026 in August 2026. It analysed 1,105 modernisation inquiries received between August 2025 and August 2026. VB6 was the source technology in 747 of them, or 67.6%.

GAPVelocity is open about the skew. Its history made it the default destination for VB6 migration questions for two decades, and the report says the 67.6% should be read as an upper bound for the wider market. The more useful finding is what starts a project. According to the report, a working VB6 application creates no pressure to move. The trigger is almost always external, such as a Windows rollout, an acquisition, a compliance audit, a failed 32-bit dependency or the retirement of the one developer who understands the system.

The same report puts the median VB6 application scoped for modernisation at about 124,000 lines of code, across 314 sized applications. That is a useful sanity check against both “it’s just a small tool” and “it will take years”.

What are the options for migrating VB6 to .NET?

There are four realistic routes. Most decisions come down to how valuable the business rules are and how long you need to keep changing the application.

Option	How it works	Good fit when	Watch out for
Keep and contain	Leave the code alone. Isolate the app on a locked-down image or VM, archive install media and licences, document the build, restrict database access.	The app is stable, rarely changes and will be retired soon.	It buys time only. The knowledge gap keeps growing.
Automated conversion	A tool such as GAPVelocity’s VB6 AI Migrator or its VELO platform translates VB6 into C# or VB.NET, then engineers finish the remainder.	Large, consistent codebases where keeping the current structure is acceptable.	The output mirrors VB6 design. The manual remainder is the hardest code.
AI-assisted rewrite with characterisation tests	Record current behaviour in tests, then rebuild module by module on .NET 10, with AI agents writing most of the code under review.	The rules are valuable, the structure is poor, and you want a maintainable result or a web front end.	Needs people who know what “correct” looks like. Capturing behaviour takes real time.
Replace with off-the-shelf software	Move the process into a SaaS or packaged product and migrate the data.	The app does something generic, such as CRM, stock control or timesheets.	Custom rules rarely fit, so the process changes to suit the product.

I use GAPVelocity as the conversion example because it is the best-known name in this niche and it publishes its numbers. Its VB6 page says VELO automates up to 95% of the conversion into C# and Blazor, starting from a free assessment and ending in a fixed-price engagement. Other vendors exist. Ask each of them the question at the end of the next section.

Why do VB6 converters stall at the last 5 to 10%?

GAPVelocity’s FAQ says the goal for most migrations is 90 to 95% automation, with the remaining 5 to 10% needing manual work. Its VB6 page calls that remainder the hardest part and names tangled global state, ActiveX quirks and undocumented data access. That is a vendor describing its own product candidly, and it matches the way VB6 applications were built. Three things make the remainder expensive.

The percentage counts code, not effort. Declarations, simple logic and form layouts convert well. The leftover share is where business rules, error handling and third-party controls live, so budget for it as the expensive part of the project.
Behaviour hides in the UI. VB6 logic is spread across form events, control properties, module-level globals and COM references. GAPVelocity’s report says this defeats procedure-by-procedure translation. Converted code can compile and still behave differently, for example when events fire in a different order.
A VB6 form has no agreed target. The report says target architecture decisions still need engineering judgement. Converting to WinForms keeps the old shape. Moving to the web means a redesign that no converter does for you.

Compiling is the easy milestone. The question to ask any vendor, including me, is how they will prove the new application gives the same answers as the old one.

How does an AI-assisted VB6 rewrite work?

This is the approach I use. AI coding agents now write good C# from a clear specification. They have no way of knowing what a twenty-year-old pricing routine is supposed to do. The method closes that gap with tests, and it keeps the honest maths from my AI migration reality check in view: AI shortens the coding, while testing and sign-off still run at human speed.

Inventory. List every form, module, class, OCX, COM reference, database, file and printer the app touches. Confirm the source you have actually builds the version running in production.
Record behaviour. Write characterisation tests that capture what the current app does: inputs, database changes, generated files and reports. Where the code cannot be called directly, test at the database or file boundary.
Choose the target. For a desktop tool with a handful of users, WinForms on .NET 10 is often the cheapest landing place. If users are remote or need a browser, design a web front end and keep the rules in a C# service layer.
Migrate in slices. Rebuild one module at a time. AI agents write most of the code and a senior engineer reviews every change. A slice is done when it passes the recorded tests.
Run in parallel, then switch. Feed old and new the same inputs for a period, compare the outputs, and retire the VB6 version once they agree.

Microsoft’s GitHub Copilot upgrade agent does not cover this. Its list of supported project types includes .NET Framework and modern .NET projects, Visual Basic .NET among them, but not VB6.

If you want to see the method on your own code first, the Modernisation Blueprint migrates one real screen with passing characterisation tests in two weeks as a fixed-price package from £20,000, and ends with a fixed price for the rest.

Which VB6 migration option should you choose?

Contain if nobody needs to change the app and it will be retired soon. Do the containment work properly.
Convert if the codebase is large and consistent, you can live with VB6-shaped C#, and you have a test plan for the remainder.
Rewrite with tests if the business rules are valuable and you expect to keep developing the application.
Replace if the app does something a mature product already does well.

Whichever route you take, start by finding out what the application depends on: controls, drivers, installers and the people who understand it. That list usually decides the answer for you.

VB6 in 2026: Does It Still Run on Windows 11, and How Do You Migrate It to .NET?