Migrating VB6 to VB.NET

Analogy categoryAnalogies

Why VB6 and VB.NET Are Fundamentally Different Platforms

It's tempting to think of VB.NET as 'VB6 with new features,' but the two are fundamentally different platforms: VB6 compiles to native x86 code and runs against COM (the Component Object Model) with manual, reference-counted memory management, while VB.NET compiles to CIL and runs on the CLR with automatic garbage collection and full access to the .NET Base Class Library. This means a VB6 application cannot simply be 'upgraded' in place -- there is no compiler flag that turns VB6 source into VB.NET source without semantic changes, because core language behaviors differ: VB6's default property syntax, its On Error Resume Next idiom used pervasively for control flow, its 1-based or user-defined array bounds, and its implicit COM object lifetime all have no direct, behavior-identical equivalent in VB.NET.

🏏

Cricket analogy: Assuming VB.NET is just 'VB6 with new features' is like assuming Test cricket and T20 are the same game because they share a bat and ball, when in fact the strategic fundamentals, over limits, and even fielding restrictions differ enough that a Test specialist can't simply 'upgrade' into T20 without relearning the format.

Common VB6 Idioms That Need Rewriting

The On Error Resume Next / On Error GoTo 0 model from VB6, where an error sets a global Err object and execution simply continues at the next line unless checked, has no equivalent in VB.NET, which uses structured Try...Catch...Finally exception handling exclusively; every VB6 procedure that relies on checking Err.Number after risky operations needs to be rewritten as a Try/Catch block. Similarly, VB6's default (parameterless) properties -- where TextBox1 = "Hello" implicitly meant TextBox1.Text = "Hello" -- are not supported the same way in VB.NET except for indexers, so every implicit default-property assignment must be made explicit. VB6's ADO (ActiveX Data Objects) and DAO data-access code must be rewritten against ADO.NET's disconnected DataSet/DataAdapter model or, in modern migrations, replaced entirely with Entity Framework Core, since ADO's connected Recordset object doesn't exist in .NET.

🏏

Cricket analogy: Rewriting On Error Resume Next as Try/Catch is like replacing an informal, unwritten team rule about who backs up a throw with an explicit, codified fielding plan the whole team drills, converting implicit assumed behavior into explicit, verifiable structure.

vbnet

' VB6 style (pseudocode, not valid in VB.NET):
' On Error Resume Next
'     conn.Open
'     rs.Open "SELECT * FROM Customers", conn
' If Err.Number <> 0 Then MsgBox "Failed: " & Err.Description

' VB.NET equivalent using structured exception handling and ADO.NET
Imports System.Data.SqlClient

Public Function GetCustomers() As DataTable
    Dim table As New DataTable()

    Try
        Using conn As New SqlConnection("Server=.;Database=Sales;Integrated Security=true;")
            Using adapter As New SqlDataAdapter("SELECT * FROM Customers", conn)
                adapter.Fill(table)
            End Using
        End Using
    Catch ex As SqlException
        MessageBox.Show("Failed: " & ex.Message)
    End Try

    Return table
End Function

Migration Strategies: Interop, Upgrade Wizard, and Rewrite

There are three broad migration strategies, and choosing the wrong one for your codebase's size and risk tolerance is the most common cause of failed migration projects. COM interop lets a VB.NET application continue calling an existing, unmodified VB6 COM DLL through a Runtime Callable Wrapper (RCW), which is useful as a temporary bridge during a phased migration but adds marshaling overhead and doesn't remove the VB6 runtime dependency. Visual Studio's old Upgrade Wizard (available up through VS 2008, and via third-party tools like Mobilize.Net's VBUC for modern versions) mechanically translates VB6 syntax to VB.NET syntax, but historically produces code riddled with Upgrade_Support compatibility shims and TODO comments flagging constructs it couldn't translate automatically, meaning the output still requires substantial manual cleanup. For all but the smallest VB6 applications, a targeted manual rewrite -- guided by the automated tool's output as a reference, but reworked to use idiomatic .NET patterns (dependency injection, proper data access, structured exceptions) -- produces far more maintainable long-term code than accepting the mechanically translated output as final.

🏏

Cricket analogy: Choosing between COM interop, the Upgrade Wizard, and a full rewrite is like a team choosing between fielding a stopgap replacement player, using a computer-simulated batting order, or fully rebuilding the squad from the academy up, each has different speed-versus-quality tradeoffs.

COM interop (via Runtime Callable Wrappers) is a good short-term bridge for large VB6 codebases that must migrate incrementally, letting new VB.NET modules call unchanged legacy VB6 COM components while the rest of the application is migrated piece by piece over multiple release cycles.

Data Type and Control Array Pitfalls

VB6's Variant data type, which could hold any value and silently coerce between types, has no equivalent in VB.NET beyond Object, and unlike Variant, Object requires explicit casting or CType/DirectCast before you can use type-specific members, so code that relied on Variant's implicit coercion (like automatically treating an empty string as zero in arithmetic) breaks and must be rewritten with explicit type checks. VB6's Control Arrays -- multiple controls sharing one name and an Index parameter, commonly used for dynamically adding rows of buttons -- also have no direct VB.NET equivalent; the standard replacement is a List(Of Button) (or similar) populated at runtime, with a shared event handler that uses the sender parameter and a Handles clause (or AddHandler) to determine which control raised the event, since VB.NET does not support multiple controls bound to a single Index-based event signature the way VB6 did.

🏏

Cricket analogy: VB6's Variant silently coercing types is like an old scoring system that automatically guessed whether a scribbled mark meant a four or a six, whereas VB.NET's Object type demands the scorer explicitly confirm which one it is before it counts, removing dangerous ambiguity.

Do not assume automated migration tool output (Upgrade Wizard or VBUC) is production-ready. These tools commonly wrap untranslatable constructs in Microsoft.VisualBasic.Compatibility shim calls or leave explicit TODO/UPGRADE_WARNING comments; every one of these must be manually reviewed and resolved before the migrated application is considered complete, since shimmed code often carries subtly different runtime behavior than the original VB6 semantics.

VB6 (native, COM-based) and VB.NET (CIL, CLR-based, garbage collected) are fundamentally different platforms, not just different syntax versions of the same language.
On Error Resume Next has no VB.NET equivalent and must be rewritten as structured Try...Catch...Finally exception handling.
VB6's implicit default properties and ADO Recordset-based data access must be made explicit and rewritten against ADO.NET or Entity Framework.
The three migration strategies are COM interop (bridge), automated Upgrade Wizard/VBUC translation, and manual rewrite, each with different speed-versus-quality tradeoffs.
Automated migration tool output typically requires substantial manual cleanup and should never be treated as production-ready without review.
VB6's Variant type has no direct VB.NET equivalent; Object requires explicit casting, unlike Variant's implicit type coercion.
VB6 Control Arrays must be replaced with a dynamic collection (e.g., List(Of Button)) plus a shared event handler that identifies the triggering control via the sender parameter.