Visual Basic 6

VB6 modernisation, with the business rules intact.

VB6 forms and business logic are still in production everywhere, running work nobody wants to touch. We read your Visual Basic 6 application into a model and generate clean, standard TypeScript / React from it, 90%+ automated, then prove the result behaves like the original.

Who this is for

A working VB6 application nobody can safely change.

VB6 modernisation (or modernization, if you are in the US) is for teams whose application still works, but has become something they maintain around rather than improve.

  • A Visual Basic 6 line-of-business application that still runs part of the business every day.
  • Changes have slowed or stopped, because nobody can say how far a change to one form or module will reach.
  • The people who wrote it have left or are close to retiring, and new hires do not learn VB6.
  • The application is too large, or too important, to rewrite from scratch on a guess about what it does.
Why now

Why VB6 is a dead end, specifically.

Age is not the real problem. The problem is that there is no way forward from where VB6 stands.

The tools are gone

Microsoft ended support for the VB6 development environment in 2008. There is no supported way to open, edit, or compile a VB6 project on a modern toolchain, so every change is made with tools that stopped moving long ago.

The runtime is a commitment, not a roadmap

Microsoft’s Support Statement for Visual Basic 6.0 on Windows says the VB6 runtime is supported for the life of supported Windows versions. That keeps the application running. It does not give you a way forward, and the runtime gets harder to keep alive with every Windows release.

There is no upgrade path in the language

VB.NET is a different language, not a newer version of VB6. The code does not carry across by opening it in a current Visual Studio, and the old Upgrade Wizard produced code that usually needed as much rework as a rewrite.

The knowledge is leaving

VB6 skills sit with developers near or past retirement. Every year the pool of people who can safely maintain the code gets smaller.

Your options

Four ways to deal with a VB6 application.

Two questions decide most of it: is the application small or large, and do you want another desktop app or a web app you can staff?

  1. Stay on VB6

    Reasonable only as a short bridge while you plan the move.

  2. Rewrite in .NET

    Can suit a small application you want to keep on the desktop. On a large one, the undocumented behavior in the forms and code has to be worked out again by hand.

  3. Rebuild as a web app

    Worth it when the business process itself is changing. It is the highest-effort path, and you take on the full risk of rebuilding the business logic.

  4. Automated conversion

    Read the real VB6 source and generate a modern equivalent. Usually the lowest-risk route for a large application you need to keep running.

How we do it

Read it, model it, generate from the model.

A hand rewrite works your business rules out again from documentation and memory, which is where undocumented behavior gets lost. We carry them across from the real source instead.

01

Map the whole codebase

Code Analyzer reads every line of the VB6 source: every form, module, and dependency, along with the data access and the business rules buried inside them. From that we build a model of how the application actually behaves. Gaps are surfaced, not guessed.

02

Generate from the model

Code Transformer maps the model onto a modern architecture and generates a TypeScript / React application from it, 90%+ automated. The new code is generated from the model, not translated line for line, so you get a clean application rather than old workarounds rewritten in a new language. For the custom pieces no automated conversion can handle, our engineers work with AI assistance and check the result against your original system.

03

Prove it matches

Side-by-side testing runs the new system and the old one on the same inputs and compares what comes out. The business rules held in the model give a second, separate check that does not rely on the tests alone. Automated test coverage is built alongside the transformation.

Financial services

Millions of lines of VB6, mapped in two months.

A financial services firm had a VB6 codebase that had grown to millions of lines. Nobody could tell how far the impact of a change would reach, so updates and new features had stalled entirely.

Code Analyzer mapped every dependency in the codebase. With that visibility, the team completed a concrete migration plan in two months, and a programme that had been stuck could move again.

What you get

A modern application you own outright.

Standard TypeScript / React

Clean, conventional code, or Vue and similar frameworks where your standards call for it. Readable by any web developer you hire.

No proprietary runtime

There is no Vivify runtime under your application and no license you must keep paying to run your own software.

Code your team owns

You can host it, maintain it, and extend it yourselves, with no dependency on us to keep it running.

Responsive on any device

A web application that works across desktop, tablet, and mobile instead of a Windows-only install.

A track record across major enterprises

VB6 modernisation

Common questions.

Is Visual Basic 6 still supported by Microsoft?

Partly. Microsoft ended support for the VB6 development environment in 2008. Under its Support Statement for Visual Basic 6.0 on Windows, the VB6 runtime is supported for the life of supported Windows versions. Your application can keep running, but there is no supported way to build or change VB6 code on a modern toolchain.

Should we move our VB6 application to .NET or to the web?

A small application you want to keep on the desktop can be rewritten in .NET. For a large application you need to keep, a web application in standard code is easier to staff and extend. Our VB6 migration guide on the blog compares the options in more detail.

How much of a VB6 application can be converted automatically?

In our projects, conversions from stacks like PowerBuilder, VB6, and Nexaweb run at 90%+ automation. The remainder, the custom pieces no automated conversion can handle, is done by our engineers with AI assistance and checked against the original system.

How do we know the new application behaves like the old one?

Business rules move across through a model built from your real code, so nothing is re-typed by hand and nothing is guessed. We then check the result two ways: side-by-side testing on the same inputs, and the business rules held in the model as a separate check.

Do we need Vivify to run or maintain the result?

No. The output is standard TypeScript / React with no proprietary runtime and no license to keep paying. Your team can host it, maintain it, and extend it without us.

Where does a VB6 modernisation project start?

Usually with an assessment: a complete dependency map, risk scoring, an effort model, and a costed migration plan, produced from your own source code in 3 to 5 weeks. If you would rather see output first, we can run a proof of concept on a representative slice of your code.

Find out what your VB6 application contains, and what it will take to move it.

Start with a fixed-scope assessment built from your own source code, or send us a representative slice of the application for a proof of concept.