VB6 modernisation and migration

The runtime is fine. Microsoft ships the VB6 runtime with Windows 11 and has said it will support it for the life of the operating system, so a compiled VB6 program usually installs and runs on a new PC. That's why so many are still going.

The tooling around it is a different matter. The IDE stopped being supported in 2008 and doesn't install on a modern machine without workarounds. The database drivers it was written against, Jet and old versions of ADO, are the usual point of failure. Third-party controls, the OCX and ActiveX components most VB6 apps lean on, come from companies that no longer exist. And the people who wrote VB6 for a living are retiring.

So the system keeps running, right up until something around it moves: a Windows update that breaks a control, a SQL Server upgrade the driver can't talk to, a report engine that won't register on a new PC, or the one developer who knew it stepping back.

Twenty years of business rules, and they're the valuable part.

Most VB6 business systems were built by one or two people over a long time. The forms are dense, the code behind them does the work, and the rules the business depends on live in event handlers rather than anywhere you'd look for them. There's often a Jet or Access back end that later moved to SQL Server, a Crystal Reports layer, an export to Sage, and a set of workarounds the office has learned.

None of that is a reason to throw it away. It's the specification for whatever comes next, and it's the thing a rewrite from scratch loses first.

Stabilise and keep it running. Source code into version control, if it can be found. A build that works on a current machine, with the controls it needs recorded and backed up. The database moved off Jet onto SQL Server if it isn't already, with the drivers updated. A test environment. This is the right first stage for almost every VB6 system, whatever comes after, and for some it's the whole answer for years.

Migrate to .NET in stages. Modern screens over the same data, one process at a time. VB6 and .NET can run side by side against the same SQL Server database, so a new .NET screen can replace one VB6 form while the rest of the system carries on. The business rules move across as they're understood, with the old form kept until the new one has proven itself. This is the path most systems take.

Replace with a web application. When the business needs the system outside the office, on phones, or shared with customers, the target is the web rather than the desktop. Same staged approach: the web version grows alongside the VB6 system on the same data, process by process.

Automatic conversion tools exist that turn VB6 into VB.NET or C#. They can help with reading an old system. As a migration, they produce code that compiles and then gets rewritten, because it carries every VB6 habit into a language that doesn't want them.

It stays where it is, or moves once, carefully. If the back end is Jet or Access, the first stage moves it to SQL Server, which both the VB6 system and anything new can share. If it's already SQL Server, nothing moves at all until a process is migrated, and then only that process's data is touched.

Nothing meets a change until the change has proven itself somewhere else: built and tested on a copy in a test environment, then run in staging alongside the live system with the data reconciled there. Only when the tests have shown it's safe does anything connect to live, and the VB6 system stays available as a fallback.

Yes, and it should be. The reason VB6 migrations fail is the big-bang rewrite: a long build of a replacement in parallel while the business changes underneath it, then a cutover weekend that goes wrong. Staged migration means one process at a time, each one live and paid for before the next starts, and the option to stop at any stage with a system that's better than it was.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a VB6 system that means reading the code and the database, finding out whether the source and the controls exist, and pricing each of the three paths as a fixed number. Each stage after that is priced before you commit to it. What drives the price and the payment terms each have a page.

Two that are dated and one that isn't. Windows Server 2016 support ends in January 2027, and SQL Server 2016 security updates ended in July 2026 for most licence holders; a VB6 system on either loses its security updates with them. The undated risk is people. Every year fewer developers can read VB6 fluently, and the one who built yours will retire.

The runtime working on Windows 11 buys time. It doesn't replace the people who understood the code.

Marc Allington built business systems in VB before .NET existed and has migrated them since, so a VB6 form is familiar ground rather than archaeology. The approach is the same as every takeover: understand, stabilise, then modernise one safe step at a time, on open technology in your own accounts, with full source code and ownership transferring to you on final payment.