VB.NET to C# migration: what you need to know before you start

Let us start with the question most people are actually asking when they search for this: is VB.NET dead, and do I have to migrate?

The direct answer: VB.NET is not dead in the sense that Microsoft has abandoned it. It runs on .NET 10. It gets security updates. You can migrate a VB.NET codebase from .NET Framework to .NET 10 without converting a single line to C#, and it will build, run, and behave correctly.

But Microsoft stopped adding new language features to VB.NET in 2017. The tooling investment, the community, the NuGet ecosystem, and the hiring pool are all overwhelmingly C#. Teams that stay on VB.NET are not making a technical error today — they are taking on a strategic risk that compounds over time.

That is the context. The rest of this guide is for teams that have decided to make the move and want to understand what they are getting into.

What actually happens when you convert VB.NET to C#

The mechanical conversion — taking VB.NET syntax and producing equivalent C# syntax — can be done with automated tools. Visual Studio has a built-in converter. There are third-party tools that do a more thorough job. They work, in the sense that the output compiles and the tests pass.

The problem is that automated conversion produces C# that reads like VB.NET. The idioms are wrong. The patterns are wrong. You end up with C# that any experienced C# developer will immediately recognise as converted code — verbose where C# is concise, explicit where C# uses inference, and carrying habits from VB.NET that have no C# equivalent and were simply transliterated rather than rethought.

This matters because code that reads like converted VB.NET accumulates technical debt. The next developer to work on it writes in the style they find, and the codebase never properly becomes C#. You get the cost of the conversion without getting the benefit.

A conversion done properly has two stages: the automated pass to get something that compiles, and a human review pass to bring the code up to idiomatic C#. Budget for both.

The three categories of conversion complexity

1. What converts cleanly

Most of the codebase — data models, business logic, LINQ queries, Entity Framework, ASP.NET controllers, service classes — converts with minimal manual intervention. The automated tools handle this reliably. If your application is mostly doing data processing, API calls, and database operations in reasonably structured classes, the conversion is straightforward.

2. What needs careful attention

Late binding. VB.NET allows you to call methods on objects declared as Object — the compiler resolves them at runtime. C# requires the type to be known at compile time unless you explicitly use dynamic. Late-bound code converts to dynamic, which compiles but bypasses static analysis and introduces runtime risk. Every instance of dynamic in the converted output is a debt item that should be reviewed and typed properly.

Optional parameters and named arguments. VB.NET uses these extensively in ways that C# supports but does not idiomatically favour. The conversion usually works, but the resulting C# method signatures can be awkward and deserve a review pass.

Error handling patterns. VB.NET%27s On Error GoTo — legacy structured error handling — converts to something that compiles in C# but is not idiomatic and is harder to reason about than standard try/catch. Any converted error handling should be reviewed and rewritten.

3. What trips people up

COM interop. If your VB.NET code calls Windows COM components — Office automation, legacy ActiveX controls, shell integration — those calls are VB.NET-idiomatic in ways that do not translate cleanly to C#. COM interop in C# works but requires more explicit handling of runtime callable wrappers, marshalling, and release semantics. This is the area most likely to produce subtle runtime errors that automated tests miss.

The My namespace. VB.NET has a My namespace — My.Application, My.Computer, My.Settings, My.User — that provides convenient shortcuts to application-level functionality. C# has no equivalent. Code using My needs to be rewritten against the underlying .NET APIs, which is usually straightforward but not mechanical. Every instance needs a human decision.

WinForms event model differences. VB.NET%27s WinForms event handling syntax — Handles keyword, WithEvents — does not have a direct C# equivalent. The conversion tools generate C# event subscription code in the constructor or InitializeComponent, which works correctly but changes the structure of the form files meaningfully. If you have a lot of WinForms code, expect more manual review in these files.

The sequencing question: framework first or language first?

This is a genuine architectural decision and the right answer depends on your team and your risk appetite.

Option A — Migrate the framework first, convert the language second. Move the VB.NET codebase from .NET Framework to .NET 10, get it stable and tested, then do the VB.NET to C# conversion as a second phase. Lower risk at each step. Easier to isolate problems. Takes longer overall.

Option B — Convert the language and migrate the framework together. One larger piece of work, one integration and test phase. Faster overall if it goes well. Higher risk if it does not — when something breaks, you have two variables to investigate.

For most teams, Option A is the safer choice. It lets you validate the framework migration independently before introducing the language change. The exception is a smaller, well-tested codebase where the team is confident in their test coverage — in that case, doing both together is reasonable and saves time.

How long does it take

A VB.NET to C# conversion adds roughly 30 to 50 per cent to the framework migration timeline. A mid-size application that would take 10 weeks to migrate framework-only takes 13 to 15 weeks if the language conversion is included.

That estimate assumes the two-stage approach — automated conversion followed by a human review pass. If you skip the review pass, the conversion is faster but the output quality is lower. In practice, teams that skip the review pass pay for it later in maintenance time.

The parts of the codebase with COM interop, My namespace usage, or heavy WinForms event handling take disproportionately longer than their size suggests. A 500-line WinForms form with complex event handling can take as long to convert properly as 5,000 lines of clean business logic.

Before you start

The most useful thing to do before committing to a VB.NET to C# migration is to understand what you are actually dealing with — specifically, how much of the codebase falls into the straightforward category versus the problematic one. The proportion of COM interop, My namespace usage, late binding, and legacy error handling in your code is the single biggest variable in the timeline and cost estimate.

A codebase audit covers exactly this. In five working days, you get a written breakdown of your VB.NET codebase — what converts cleanly, what needs manual intervention, where the risks are, and a realistic effort estimate for the full conversion. That is the right starting point before you commit developer time to a project of this kind.