Migrating from VB.NET to C#: A Practical Roadmap

Migrating a VB.NET codebase to C# is one of the most common .NET modernisation projects. Teams undertake it to access a larger pool of C# developers, use C#-first libraries and features, align with the wider .NET ecosystem, and reduce cognitive overhead of maintaining a multi-language codebase. This guide covers how to approach the migration strategically and avoid the common pitfalls.

Connect on LinkedIn →

Before You Start: Assess the Scope

A VB.NET to C# migration is primarily a syntax translation — both languages target the same IL and use the same runtime. But scope assessment matters before committing. Count your .vb files and lines of code. Identify VB-specific features: With...End With blocks, On Error Resume Next, My.Application, late binding (Option Strict Off), and XML literals. These require more than mechanical translation.

Migration Strategies

Big bang: rewrite everything at once

Only viable for small codebases (under ~5,000 lines). The whole project is translated and tested before going live. Risky for large codebases because bugs accumulate and it's hard to stay in sync with ongoing VB.NET changes.

Strangler fig: migrate file by file

The recommended approach for most projects. VB.NET and C# projects can coexist in the same .NET solution — they compile separately but reference each other freely. Migrate one class or module at a time, running tests after each. Development continues on the VB.NET codebase while migration proceeds; new features are written in C# from day one.

Automated tools + manual review

Tools like CSharpToVBConverter, Telerik Code Converter, and Roslyn-based tools can automate most mechanical translations. The output always requires manual review — automated converters handle common patterns well but struggle with VB-specific idioms, late binding, and COM interop.

VB.NET Features With No Direct C# Equivalent

On Error Resume Next / On Error GoTo

VB's legacy error handling must be replaced with try/catch. This often requires structural refactoring — On Error Resume Next is particularly tricky because it silently suppresses all errors, and the equivalent C# code needs to explicitly handle or log each error.

With...End With blocks

Translate to a local variable and explicit property access:

' VB.NET
With myObject
    .Name = "Alice"
    .Age = 30
    .Save()
End With

// C#
var obj = myObject;
obj.Name = "Alice";
obj.Age = 30;
obj.Save();

XML Literals

VB.NET's XML literals (inline XML in code) have no C# equivalent. Replace with XDocument.Parse(), XElement constructors, or string interpolation depending on the use case.

Optional parameters with ByRef

VB.NET allows optional parameters to be passed ByRef. C# allows ref and optional parameters separately but not combined. Refactor these into overloads or use a wrapper method.

String functions

VB.NET has a large set of legacy string functions (Left(), Right(), Mid(), Len(), InStr()). All have direct string method equivalents in C#: Substring(), Length, IndexOf(), etc.

Testing Your Migration

The most important investment before migrating is a solid test suite. Unit tests for business logic, integration tests for database and API interactions, and end-to-end tests for critical user flows all provide a safety net. A class that passes the same tests in both VB.NET and C# is almost certainly a correct translation.

Run tests after every file migration. If you don't have tests, write characterisation tests (tests that capture current behavior without asserting correctness) before migrating — they'll catch regressions even if the original behavior wasn't ideal.

Post-Migration: Modernise

Once migrated to C#, you're positioned to adopt features that VB.NET doesn't support or support less well: records, pattern matching, nullable reference types, default interface members, and top-level statements. Treat the migration as the foundation for modernisation, not the end goal.