Practice · 10
Migrating VB6 Applications Today
Your EXE still runs. The person who wrote it retired in 2019. This is the honest guide to what happens next.
01Start from the true facts
Two facts define the situation, and both are more comfortable than the folklore suggests. First, the VB6 runtime is not abandoned: under Microsoft's "It Just Works" commitment, documented in the VB6 deep dive, the runtime ships and is supported in current Windows, a program that ran on Windows 2000 runs on Windows 11. Second, the IDE is nonetheless end-of-life since 2008: no security patches, no store availability, no support ticket you can file. The result is the classic legacy equilibrium (stable enough that nothing forces your hand), unsupported enough that nothing holds it. Any honest migration strategy starts by admitting both facts at once.
02Inventory before architecture
The first phase of every migration is not technical but archaeological. Where is the source? A remarkable number of "VB6 systems" exist only as compiled EXEs because the project directory died with a file server in 2011, and recovering maintainable source from a binary is archaeology of a much crueler kind. For systems with source, the inventory that matters: external dependencies (OCX and ActiveX controls, whose vendors often no longer exist), data access (DAO, RDO, or the ADO of the late period), COM interop with Office and third-party applications (the automation patterns in the code depot), reports, and installation tooling. Every hidden dependency you find during inventory costs an afternoon; every one you find during migration costs a month.
Check the small stuff early: a single grid control or charting OCX from a defunct vendor has decided more migration architectures than any number of executive steering committees.
03The four options, honestly weighed
- Keep. Supported runtime, known risks: no patches for the IDE, a shrinking pool of fluent maintainers, and a hard 32-bit ceiling. Rationally defensible for stable, low-change systems (the runtime promise exists precisely for this population). Revisit annually, not daily.
- Contain. Keep the core EXE, wrap its edges: virtualised environments, documented workarounds, and .NET shim layers that interop with the VB6 COM surface so new development happens around the old core rather than inside it. The most common real-world compromise.
- Convert. Commercial conversion suites have carried many codebases to C# or VB.NET: the target landscape is surveyed in the Great Split analysis. They convert mechanics reliably (syntax, forms, data access) and semantics approximately (error handling, late binding, control events). Budget as much for conversion verification as for conversion itself.
- Rewrite. Sometimes the honest answer: the business logic is the asset, the implementation is a liability, and the rewrite (often web-first, test-first, in a stack your team can actually hire for) repays the investment. Most expensive, most durable, and correct more often than legacy loyalists admit.
04The playbook
- Freeze and inventory, collect source, binaries, dependencies, and the one person who still remembers what the March override button does.
- Assess blast radius (which systems consume this one), and what breaks downstream if behaviour drifts by a rounding error.
- Pick per system, not per portfolio, a stable report tool earns "keep"; a system awaiting new business rules earns "convert" or "rewrite". Portfolios rot precisely when one answer is applied to everything.
- Pilot one system end-to-end (including deployment, training and the awkward integrations nobody documented) before committing the fleet.
- Ring-fence knowledge: the classic VB community and its archives are an operational resource; treat them as part of your support contract.
Legacy strategy is not a technology decision. It is a risk-management decision that happens to know how to compile.
05The 2026 verdict
The depot's counsel, offered to readers who manage such systems: decide deliberately. The worst outcome is the default one: a decade of "we'll migrate next year" that leaves you with the costs of both strategies and the benefits of neither. The runtime buys you the luxury of choosing on business grounds; the whole point of that luxury is to use it. For the surrounding context (why these systems exist at all, and what the tooling was like to build them in) circle back through the complete history and the timeline.
Continue through the depot
