VB6 migration: how to move off Visual Basic 6 without putting the business at risk

You should migrate a VB6 application when keeping it becomes riskier than replacing it: controls that no longer install, the original developer gone, a need for remote access or customer-facing features, or machines nobody dares to update. There are four realistic paths: contain the application for now, convert it to VB.NET or C#, rewrite it as a .NET desktop application, or rebuild it for the web. Microsoft itself recommends replacing VB6 applications, but nothing forces you to do it all at once.

This guide is for the executive who has to decide. Most of what ranks for "VB6 migration" is written by conversion tool vendors and offshore services firms. It is useful on technique and mostly silent on the questions that matter to you: when to migrate, to what, and how to keep the business running while you do.

Where Visual Basic 6 stands in 2026

Visual Basic 6 shipped in 1998. Microsoft's support statement for Visual Basic 6.0 (checked on 7 November 2026) separates several layers:

Two details matter. Runtime support is limited to serious regressions and critical security issues. And everything stays 32-bit: on 64-bit Windows, VB6 code runs only inside the WOW emulation layer. The same page is blunt: since there is no supported way to create or maintain VB6 applications, Microsoft strongly recommends replacing them with modern technology.

In plain terms: your application will not stop launching tomorrow. But every fix is made in a 1998 tool, often on an old machine kept alive for that purpose, by someone who is getting harder to replace.

Signs it is time to migrate

• The build machine is a museum piece: an old PC kept only because it is the last one where the project compiles.
• A third-party control blocks you: a grid, chart or printing control from a vendor that no longer exists, which refuses to install on a modern machine.
• The original developer is leaving, and nobody else can open the project.
• People need the software away from their desk, on a tablet or phone, or customers need access to it.
• Security reviews start asking questions: audits, cyber insurance, requirements from a large customer. A 32-bit application built on old components rarely passes them comfortably. See our business application security essentials.

When it is better to wait

A VB6 application that works, rarely changes, relies on no fragile third-party controls and serves office-based users can wait. If so, contain it:

• keep machines and servers patched, with only the application itself being old;
• restrict network access, with no direct exposure to the internet;
• document the install and test it on a clean machine;
• check backups with a real restore;
• archive the source code and the build environment.

Treat that as a planned pause: set a review date, and start the migration as soon as one of the signs above appears, rather than in a panic the day a machine will not run the application.

Migration paths compared

VB.NET: closer than it is

VB.NET keeps VB6 keywords, which makes migration look like an upgrade. It is really a different language on a different platform: strict typing, structured exception handling, rebuilt forms, new data access. And in March 2020 the Visual Basic team wrote that Microsoft does not plan to evolve Visual Basic as a language. It remains usable and supported, but it is not the most durable target for a project starting today.

C# and .NET

This is the most common VB6 target. Commercial converters translate a good share of the code. Their advertised automation rates are sales figures, to be tested on a sample of your own project. The result can stay a Windows desktop application, if your users need one, or become the base of a web application on ASP.NET Core. It is the natural choice when your IT is already built around Microsoft: SQL Server, Entra ID, Microsoft 365.

Rebuild as a web application

The application runs in a browser, on desktops, tablets and phones, with a database such as PostgreSQL or SQL Server and APIs for integrations. The VB6 code becomes the specification: you read the calculations, checks and edge cases instead of translating line by line. This path takes the most design work and opens the most possibilities, from customer portals to mobile access to ERP integration. For stack choices, see how to choose a tech stack for business software.

Traps specific to VB6 applications

ActiveX controls and DLLs

A typical VB6 application is assembled from OCX controls: grids, calendars, charts, tabs, serial communications. Microsoft's own controls usually have a .NET equivalent. Third-party ones often do not, and Microsoft does not support them. Add direct Windows API calls and in-house DLLs, and you have a list to inventory before any serious estimate.

The Access database behind it

Many VB6 applications read a Microsoft Access .mdb file through DAO or ADO, often on a network share. That pairing brings its own problems: corruption, locking, size limits. Moving the data follows the same logic as converting an MS Access database to a web app. When the data already lives in SQL Server, it can often stay put during the transition, which makes coexistence much simpler.

Printed reports

Crystal Reports, the VB6 Data Report designer or hand-drawn printing code: an older application often has dozens of reports, invoices, delivery notes and labels. Each one is rebuilt as a PDF or for the specific printer, and quotes almost always underestimate them.

Data and types

VB6 tolerates a lot: untyped variables, dates stored as text, empty values treated as zeros. Those habits leave marks in the data. Moving it requires cleaning and trial migrations signed off by the business, as described in our guide to legacy data migration.

Buried business rules

Pricing, discounts, due dates and validation checks written in button click handlers, sometimes duplicated across several forms. You recover them by reading the code, if you have it, and by watching users work. If the source code is lost, conversion is impossible and a rewrite guided by observation is the only route.

Migrate in stages

A single big-bang cutover concentrates every risk on one date. The safer sequence:

1. Inventory: forms and reports in real use, controls, DLLs, files exchanged with other systems.
2. Secure the existing system: archived source, reproducible build, tested backups.
3. A first module chosen for its value, usually what is most missing today.
4. A prototype validated by users before development starts.
5. Coexistence on a shared or synchronized database, with VB6 handling everything not yet moved.
6. Module-by-module cutover with a rollback plan, until the VB6 application is switched off.

The method is detailed in our guide to legacy application modernization, and the broader case of software without a vendor in replacing unsupported business software. Neighboring tools follow the same logic: see Delphi to web migration. If your "Visual Basic" actually lives in Excel macros, that is a different problem: replacing Excel VBA macros.

What a VB6 migration costs

Line count is a poor predictor. Cost depends on the forms in real use, the controls to replace, the reports, the integrations and the state of the data. What weighs most in a VB6 migration: third-party controls with no equivalent, logic duplicated across forms, and missing documentation. Cost drivers and ranges are covered in software modernization cost.

Common mistakes

• Believing a converter delivers a finished application: it delivers code that still needs work.
• Cloning every screen one to one, instead of using the migration to drop what nobody uses.
• Waiting for the breakdown: an emergency migration means weak negotiation and thin testing.
• Forgetting special workstations: barcode scanners, scales, label printers.
• Letting the original developer leave before writing down what they know.

A checklist for decision-makers

• Do you have the complete source code and a machine that builds it?
• Which third-party ActiveX controls does the application use?
• Is the database an Access file, SQL Server or something else?
• Which forms and reports are used every week?
• What need drives the migration: security, mobility, openness, key-person risk?
• Who will sign off the business rules of the new application?

Where to start

Gather screenshots of the most used screens, the list of reports and controls, and if possible a copy of the database. One conversation is then enough to tell whether to contain, convert or rebuild.

At LPR Studio, that conversation leads to a free visual prototype of the first module, presented on a video call within 5 business days, so your team sees its future screen before anyone commits. The approach is explained in see your software before you pay for it.