What the tools genuinely do well.
Worth being fair about this, because reflexively dismissing converters is as unhelpful as the sales pitch.
- Mechanical translation at volume
- Statement-for-statement conversion across thousands of files is exactly the work that should not be done by hand. Tools do it faster and far more consistently than people.
- Form and control scaffolding
- VB6 forms map reasonably onto WinForms. Having layout, control names, and event handler stubs generated saves genuine weeks of tedium.
- A compiling artifact early
- There is real project value in something that builds on day thirty. It makes the remaining work visible and measurable instead of hypothetical.
- Inventory and dependency discovery
- Even when you discard the output, running a converter surfaces every third-party control, API declaration, and orphaned form in the project. That inventory is worth having on its own.
Where the tools stop.
The output compiles. That is not the same as the output being finished, and the gap between the two is where these projects get into trouble.
- The result is VB6 written in C#
- Converters preserve structure, which is the point, but VB6 structure carries assumptions that do not belong in .NET. Global state, the form as controller, and business logic living in event handlers all survive translation intact.
- Variant and late binding semantics
- VB6’s Variant and its implicit conversions have no clean equivalent. Tools emit defensive code or fall back to Object with runtime casts, and behaviour diverges at the edges in ways that only appear under real data.
- Error handling does not map
- On Error Resume Next has no honest translation. What a converter produces is syntactically valid and semantically different, and the difference stays invisible until something fails in production.
- Third-party and ActiveX controls
- Usually the hard blocker. Grids, reporting engines, and communications libraries from vendors that no longer exist have nothing to convert to, and each one becomes a separate decision with its own cost.
- No tests come out of it
- You receive code with no characterisation tests, which means no way to prove the converted system behaves like the original. On a business system, that is the part that actually matters.
The trap: converted and unmaintainable.
The failure we see most often is not a conversion that fails. It is a conversion that succeeds, ships, and leaves an organisation with a C# codebase only the original VB6 developers can navigate, no tests, and a fresh belief that the modernization is finished.
The old system was at least honestly old, and everyone knew where they stood with it. A mechanically converted codebase looks modern in the repository and behaves like 1998 in practice, and the budget that would have fixed it was spent proving the conversion worked.
If you take the automated route, the refactoring phase is not optional polish. It is the second half of the project, and it belongs in the plan and the budget from the start.
How we approach it.
We are not purists about this. Tooling that removes weeks of mechanical typing is tooling worth using, and we use it where it fits.
What we do not do is let the tool decide the architecture. Event Storming comes first and establishes what the business rules actually are, independently of how VB6 happened to express them. That model determines the target design, and conversion tooling becomes an accelerator inside the design rather than a substitute for having one.
In practice that means the mechanical parts get converted, the business rules get extracted and re-implemented against tests that prove parity with the original, and the third-party control decisions get made deliberately at the start instead of discovered at the end.
Automated conversion, manual rewrite, and the hybrid.
| Dimension | Automated conversion | Manual rewrite | Tool-assisted, human architecture |
|---|---|---|---|
| Speed to compiling code | Fast | Slow | Fast |
| Speed to maintainable code | Slow, if it arrives at all | Slow | Moderate |
| Preserves business rules | Structurally, yes | Only if they are found first | Yes, via extraction and parity tests |
| Produces tests | No | Depends on discipline | Yes, by design |
| Handles ActiveX and third-party controls | No | Yes, deliberately | Yes, deliberately |
| Resulting architecture | VB6 shape in .NET syntax | Whatever you design | Designed from the domain model |
| Principal risk | Unmaintainable output declared done | Cost, and rules nobody documented | Needs the second budget to be real |
Common questions
Will an automated converter produce code we can ship?
It will produce code that compiles and, with work, runs. Whether you can ship it depends on your tolerance for a codebase that carries VB6’s structure into .NET. For a system you plan to retire in two years, that may be perfectly sensible. For one you will maintain for ten, it is not.
What percentage of a VB6 project converts automatically?
Vendors quote figures and we would rather not repeat numbers we cannot verify against your codebase. The honest answer is that percentage of lines translated is a poor proxy for percentage of work completed, because the remaining lines concentrate in the hardest parts: third-party controls, error handling, and anything touching Variant.
Is VB6 actually urgent?
The IDE lost support in 2008, but the runtime has been carried forward onto current Windows releases, so a great many VB6 applications still run. Urgency usually arrives via a third-party control, a driver, or an integration rather than from VB6 itself.
Can you work with a conversion someone else already ran?
Yes. Inheriting a mechanically converted codebase is a common starting point, and the work is the same refactoring and rule extraction that should have followed the conversion in the first place.