Visual Basic 6 shipped in 1998. Microsoft ended mainstream support for the development environment in 2008, and while the VB6 runtime still ships with and runs on current versions of Windows, there is no supported way to open, edit, or compile a VB6 project on a modern toolchain. That leaves a lot of working line-of-business software in an awkward place: it still runs, but you cannot safely change it, and the people who can are getting harder to find.
If you own a VB6 application, this post covers the options that actually exist and where each one fits.
Why VB6 is a dead end, specifically
It helps to be precise about the problem, because “old” is not the real issue:
- No forward path in the language. VB.NET is a different language, not a newer version of VB6. Code does not carry across by opening it in a modern Visual Studio. The old “Upgrade Wizard” Microsoft shipped produced code that usually needed as much rework as a rewrite, which is why most teams stopped trusting it.
- The runtime clock is ticking. The VB6 runtime is supported for the lifetime of the current Windows releases, but that is a support commitment, not a roadmap. Building the next decade on it is a bet against Microsoft.
- The knowledge is walking out the door. VB6 skills are concentrated in developers near or past retirement. Every year the pool of people who can maintain the code shrinks.
The options
| Option | What it is | Timeline | Risk | Where it fits |
|---|---|---|---|---|
| Stay on VB6 | Keep running it, freeze changes | n/a | Rising | Only as a short bridge |
| Rewrite in .NET (desktop) | Rebuild in C# or VB.NET as a Windows app | Long | High | You want to stay desktop and the app is small |
| Rebuild as a web app | Redesign and rebuild for the browser | Long | High | The workflow itself is changing |
| Automated conversion | Parse the VB6 source and generate a modern equivalent | Medium | Low to medium | A large working app you need to keep, on a modern stack |
Stay on VB6
Reasonable only as breathing room. Use it to plan the move, not to put it off. The risk profile gets worse every year, never better.
Rewrite in .NET
Rebuilding in C# or VB.NET keeps you in the Microsoft world and can be the right call for a small application. For a large one, you hit the same wall every rewrite hits: the real behavior of the system lives in forms and code that were never documented, and re-deriving it by hand is slow and error-prone. You are also rebuilding as a desktop app, which may not be where you want to be in five years.
Rebuild as a web app
If the business process is genuinely changing, a fresh web build lets you design for how the work is done now rather than how it was done in 1998. It is the highest-effort path, and you take on the full risk of rebuilding the business logic from scratch. Worth it when you were going to redesign anyway, and hard to justify when the current system works and just needs a modern foundation.
Automated conversion
Automated conversion reads your actual VB6 forms, modules, and code, and generates a modern equivalent, in our case clean TypeScript and React with a real API rather than another desktop app. The value is not that no people are involved; it is that the working behavior is carried across from the real source instead of reconstructed from memory. For a large VB6 application you need to keep running, that is usually the lowest-risk way onto a stack you can hire for.
How to choose
Two questions decide most VB6 migrations:
- Is the application small or large? Small apps are fine to rewrite. Large ones are where a rewrite quietly runs over, and where carrying the logic across automatically pays off.
- Do you want another desktop app, or a web app you can staff? If the answer is the web with standard code, that narrows the field quickly.
If you want to see your VB6 application as modern code before you commit to a direction, the usual first step is a fixed-scope proof-of-concept on a real slice of the code. Get in touch and we can scope one.