If your business still runs on a Visual Basic 6 (VB6) application, you don't have to replace it overnight, but you should plan to. Microsoft still supports the VB6 runtime on current Windows versions for serious regressions and critical security issues, but the tool used to change the program hasn't been supported since 2008, and Microsoft "strongly recommends" replacing VB6 applications. Your options are to keep and stabilise it for now, wrap it so other systems can connect to it, replace it with an off-the-shelf product, rebuild it as a modern web application (a VB6 to .NET migration is one version of this), or move the work into an ERP. Whichever you choose, the first step is the same: write down exactly what the old system does, including the rules hidden in its code, before anyone touches it. The same approach applies to old Access databases and early .NET systems.
Why so many VB6 applications are still running
Many Australian businesses had a VB6 system built in the late 1990s or 2000s (for quoting, job tracking, stock, production or dispatch) and it still does exactly what the business needs. Nobody wanted to replace something that works.
Over the years, those systems picked up a lot of knowledge. A discount rule for one customer group. A calculation for freight or waste that someone worked out in 2006. A check that stops a job being invoiced before it's signed off. Much of that knowledge isn't written down anywhere except the code. That's the real asset, and it's also the real risk.
Is VB6 still supported? What Microsoft actually says
Microsoft's Support Statement for Visual Basic 6.0 separates the program you use from the tool used to build it:
- The VB6 runtime (the files that let a VB6 program run) ships with Windows and, according to Microsoft, "will be supported for the support lifetime of Windows versions". Microsoft lists Windows 10, Windows 11 and Windows Server 2016 to 2025 as supported. But the support bar is "limited to serious regressions and critical security issues for existing applications".
- The VB6 development environment (the tool used to change the program) "is no longer supported as of April 8, 2008". Microsoft says that because "there is no supported method to create or maintain Visual Basic 6 applications", it "strongly recommends that you replace your applications with modern technology".
- 32-bit only. The VB6 runtime is 32-bit, and on 64-bit Windows it runs only in Windows' 32-bit compatibility layer.
- Third-party add-ons aren't covered. Many VB6 systems use extra controls (grids, charts, report writers) bought from other companies. Microsoft doesn't support those, and some of the original vendors no longer exist.
So the honest answer is: it will probably keep running for now, but nobody supports the way it gets changed, and the risk grows each year.
The real risks of an old VB6 system
The risks are usually business risks, not technical ones:
- One person understands it. Often a former employee or a contractor who is near retirement. If they become unavailable, changes stop. This is key-person risk (the business depends on one person's knowledge).
- Changes get harder. VB6 developers are getting harder to find, and the old tools need old setups to run.
- Windows and hardware changes. A Windows update, a new server or a move to the cloud can break an old control or database driver, and there may be no fix.
- Security. Older systems often store passwords in plain text, connect to the database with full access, or need old protocols switched on.
- No remote or mobile access. Staff in the field or working from home can't use it without remote desktop workarounds.
- Hard to connect. Getting information in or out often means exports, imports or retyping. That creates double data entry (the same information typed into two systems) and information stuck in one place.
First step: document what the old system actually does
Before you choose an option, make a complete picture of the current system. Every option depends on it, including keeping it. Cover:
- Screens and who uses them. Every form, who opens it, how often and what for.
- Reports and exports. Every report, who reads it, and what decisions it drives. Some will turn out to be unused.
- Calculations. Pricing, costing, tax, freight, waste, commission, scheduling. Write down the formula and the special cases.
- Business rules. What the system stops people from doing, the approvals it enforces, the statuses a job or order moves through.
- Integrations. Every file it reads or writes, every other system it talks to (accounting software, email, label printers, scales, other databases), and any scheduled jobs that run overnight.
- The data. What's in the database, how much, how clean it is, and what history the business needs to keep.
There are two sources for this, and you need both. The code tells you what the system really does, including rules nobody remembers. The users tell you what they actually rely on, what they work around and what they'd change. Where the two disagree, you've found something important.
Your options, honestly
1. Keep and stabilise it (short term)
If the system works and the business isn't changing, it can be reasonable to keep it for now while you plan. Stabilising means: get the source code and confirm it actually builds, back up the database properly, record how the system is installed, check which add-on controls it needs, and run it on a supported version of Windows. This buys time. It doesn't fix the key-person risk or the integration problems.
2. Wrap it and connect it
Leave the old application running, but add a connection layer (often an API, a standard way for one system to send information to another) that reads from and writes to its database. Your accounting software, website or reporting can then get the information without retyping. This works well when the old system's logic is sound and the main pain is getting information in and out. It's also a good first stage of a step-by-step replacement. Our database integration and migration service covers this kind of work.
3. Replace it with an off-the-shelf product
If what the system does is fairly standard (stock, quoting, CRM, job management), there may now be a product that does it well, with vendor support and updates. The catch: your special rules may not fit. Use your documentation from the first step to test products against your real processes, not a sales demo.
4. Rebuild it as a modern web application
If the system does something specific to your business that no product covers well, rebuilding is usually the right answer. A modern web application runs in a browser, works for remote staff and connects to other systems more easily. A VB6 to .NET migration is one common path; other modern platforms work too. The aim isn't to copy the old screens exactly, but to keep the rules that matter and drop the workarounds. Our custom software development page explains how we approach this.
5. Move the work into an ERP
If the old system grew into running stock, purchasing, production and jobs, an ERP (one system that runs operations and the finance side together) may be the better home. Any rules the ERP can't handle may still need a small custom piece alongside it.
Many businesses mix these: wrap the old system now, replace one part at a time, and switch the old system off at the end. For a broader look at the choice, see our post on when to upgrade and when to replace a legacy system.
How to avoid losing the business rules
This is where most replacement projects go wrong. The new system looks right in testing and then gets a calculation subtly wrong for one customer type. To avoid it:
- Extract the rules from the code. Someone who can read VB6 goes through the code and lists every calculation and condition in plain English, so the business can confirm each one.
- Ask the users what they rely on. "What would go wrong if this screen disappeared?" finds rules the code review misses.
- Build test cases from real data. Take real past orders, jobs or quotes, run them through the old system and record the results. The new system must give the same answers, or a difference the business has agreed to.
- Decide which rules to keep. Some rules are workarounds for problems that no longer exist. Drop those on purpose, not by accident.
Data migration and running in parallel
Moving the data is a project of its own. Old databases usually have duplicates, half-finished records and fields used for something other than their name. Clean it, map each old field to the new system, and do trial migrations before the real one. Our legacy system end-of-life migration service covers this.
Where you can, run the old and new systems side by side for a period, with real work going through both, and compare the results. It's extra effort, but it's the most reliable way to catch a missed rule before the old system is switched off. Keep the old database available (read-only) afterwards so you can look up history.
A rough decision guide
- The system works, nothing is changing and the person who knows it is available: stabilise it now, document it, and plan a replacement without rushing.
- It works, but getting information in and out is the problem: wrap and connect it.
- What it does is now standard and a product fits your processes: replace it with the product.
- It does something specific to how you run the business: rebuild it.
- It has grown into running most of your operations: look at an ERP, with custom pieces only where needed.
- You don't know which applies: document the system first. That answer usually becomes obvious once you can see everything it does.
You may not need outside help for every step. If you have a developer who knows the system and the time to document it, you can do much of this yourselves. Where we help most is the documentation, the rules review, the data migration and making sure nothing is lost at cutover. Our Process & Systems Audit ($5,000) maps your processes and systems and gives you a written report if you want an independent view first.
Frequently asked questions
Is VB6 still supported?
Partly. Microsoft supports the VB6 runtime on supported Windows versions, including Windows 10, Windows 11 and recent Windows Server versions, but only for serious regressions and critical security issues. The VB6 development environment has been unsupported since April 2008, and Microsoft strongly recommends replacing VB6 applications.
Can VB6 be converted to .NET automatically?
Partly. Visual Studio included a VB6 upgrade wizard up to Visual Studio 2008; Microsoft no longer ships it, and points to third-party migration tools instead. Those tools can convert a lot of the code, but the result usually needs significant manual work: third-party controls, database access, printing, reports and error handling often need rewriting, and the converted code keeps the old design. Automated conversion can be a useful starting point; it isn't a finished system.
How do we know what our old system does?
Combine two sources. Have someone read the code and list every calculation, rule and integration in plain English, and interview the people who use it every day. Then run real past transactions through the old system and record the results, so you can check the new one against them.
Should we rebuild or buy?
Buy if what the system does is now standard and a product handles your real processes without major workarounds. Rebuild if the system does something specific to how you run your business. Many businesses do both: a product for the standard parts and a smaller custom piece for the rest.
Can you help with just part of it?
Yes. We can document the existing system, extract the business rules, connect it to your other systems, or handle the data migration, without taking on the whole replacement. If you have an old Access database in the mix, our Access database replacement page covers that too.
How much does it cost to replace a VB6 application?
Costs vary widely depending on the size of the business, how many systems are involved and how much needs to be custom-built. That's why we scope every project first and give you a fixed quote after a free initial chat.
If you're relying on an old VB6, Access or early .NET system and want to plan its replacement without losing what it does, book a free initial chat or call us on 1300 470 091.
Sources: Microsoft: Support Statement for Visual Basic 6.0 · Microsoft archive: VB6 migration wizard shipped through Visual Studio 2008