MigrationParity Visual Basic 6 to .NET — keeping every rule, dropping the runtime risk
Your VB6 application still opens every morning — on an unsupported runtime, 32-bit forever, held together by OCX controls nobody sells anymore. We move it to .NET and prove, screen by screen, that nothing changed except the foundation.
Order 4812 PARITY ✓
Illustrative screens, fictional data — the same order on both sides. The totals matching to the cent is the entire point.
The situation you are probably in
The application was written between 1998 and 2008, shipped as a single .exe plus a folder of OCX controls, and has quietly run a department — or the whole company — ever since. It still works. And every year it gets riskier:
- Microsoft ended Visual Basic 6 IDE support in 2008. The runtime is still carried on Windows 10 and 11, but nothing new is fixed — you are running on borrowed, frozen time.
- It is 32-bit forever, so it can never address more memory or load a 64-bit driver, and every new Windows build is a gamble nobody underwrites.
- Third-party OCX/ActiveX controls (grids, calendars, reporting) are unsupported or unlicensable today; one broken control can stop a form dead.
- “DLL hell” and per-machine COM registration make every new PC a manual ritual, and there is no path to web, mobile, real security or an audit trail.
- Each attempt to “just rewrite it” died because nobody could enumerate what the old app actually does — which is exactly the problem we solve differently.
How we migrate Visual Basic 6 to .NET systems
-
Assessment: map what you actually have
We inventory the code, data, reports, integrations and — crucially — which parts are still used. You get a written, risk-ranked migration roadmap at a fixed price, yours to keep whoever executes it.
-
Parity harness: capture today’s truth
Before any new code, we build an automated harness that runs your real workflows on the existing system and records the results — totals, calculated fields, rounding, sort orders. That becomes the contract the new system must satisfy; behaviour is preserved because it is tested, not assumed.
-
Data first, verifiably
A repeatable pipeline moves your data into SQL Server or PostgreSQL with counts and checksums on every run — encodings, null and date semantics, and any business logic hidden in indexes handled explicitly. The mirror runs from day one, so it is always fresh.
-
Rebuild in slices on .NET
Modules are rebuilt on .NET 8 against the mirrored data. Read-only functions (reports, lookups) move first for instant, low-risk value; write functions cut over one workflow at a time, each gated by parity. There is no weekend where everything switches at once.
-
Cutover with a way back
When the last write path passes parity, the old system becomes read-only, then an archive. You get the full parity report — evidence, not assurances — plus the documentation the legacy system never had.
What survives the migration
- Business rules pricing, rounding, validation and workflow logic buried in form events and
.basmodules — reproduced and now covered by tests. - Your data Access/Jet or SQL back ends moved cleanly, including the ADO quirks, null/date semantics and autonumber seeds that trip up naive conversions.
- The screens people know keyboard-driven entry forms can stay keyboard-driven on .NET — we do not force a new UX on users who are fast in the old one.
- Reports people trust same numbers to the cent, or a documented, signed-off explanation of every difference.
What does not survive: the unsupported runtime, the 32-bit ceiling, OCX licensing landmines, per-machine COM registration, and the fear of the next Windows update.
Related
VB6 front ends usually sit on an Access/Jet or SQL back end — see Microsoft Access migration — and sometimes alongside a FoxPro or DBF sibling (FoxPro to .NET). The decision framework in rewrite vs convert vs wrap applies to VB6 word for word.
Frequently asked questions
Should we use an automated VB6-to-.NET converter?
Automated converters turn VB6 into C# or VB.NET that compiles but reads like transliterated VB6 — the idioms of neither language, and a maintenance burden that outlives the project. We rebuild against a parity harness instead: behaviour is preserved because it is tested, not because syntax was mechanically translated. See rewrite vs convert vs wrap.
VB6 still runs on Windows 11. Why migrate at all?
The runtime runs — Microsoft carries it on supported Windows — but the IDE has been unsupported since 2008, the app is 32-bit forever, and it depends on OCX/ActiveX controls that are no longer sold or patched. It runs until one control, one driver, or one Windows change stops it. The right time to migrate is while the old system still works, because that is exactly what makes parity testing possible.
What happens to our OCX / ActiveX controls?
They get inventoried and triaged: some map to native .NET controls, some to a modern grid or reporting component, and the dead ones simply go. Where a control encodes behaviour (a formatted grid, a custom calendar), the parity harness pins that behaviour down first so the replacement is checked against reality.
Can the business keep working during the migration?
Yes — that is a hard requirement, not a nice-to-have. The VB6 application stays the system of record while we build. Data is mirrored continuously, read-only functions move first, and write functions cut over module by module, each gated by parity. There is no big-bang weekend.
Our VB6 app talks to an Access/Jet database over a share. Is that a problem?
It is the most common setup, and the first thing we stabilise. Moving the data to SQL Server ends the file-corruption and 2 GB-limit failure modes on their own, often before the front end is touched — see Access migration for how that phase works.
Start with an assessment, not a rewrite.
Send us the stack you are on and what hurts. You get a written read of your data and code, the realistic options — including the ones that cost you less — and what parity testing would cover. Fixed price, agreed before we start.