I am currently running a team of 5 VB.Net developers and have decided to make a switch to C#. The team builds and maintains around 20 different applications that run our whole platform, so the code-base is fairly moderately sized.

There are several factors for making the switch, but the biggest is to overcome recruitment issues. VB.Net developers are hard to come by in our region and over the course of this year we will be recruiting 3 or 4 more. I work with several recruitment agencies to find talent and the feedback is fairly overwhelming for this point. All of our developers already have C# experience, so I have no concerns there.

My question is not so much about the viability of switching to C#, as we are already certain on this, however what I need advice on is the approach. The way I see it there are several options:

  1. We use the team to convert the entire code base at once and then work in C# moving forward.
  2. We factor in time to convert smaller chunks of the code base during project development.
  3. We outsource the conversion to another agency
  4. We employ a new C# developer and get them started on the conversion whilst slowly migrating the team over

I'm sure there are companies who have had to make this switch in the past, so really hoping someone has advice from experience.

The question (for clarity): What is the best approach for migrating a team from VB.Net to C# with all of the considerations above?

  • 2
    I'm sorry, but what was the question again ?
    – Machado
    Apr 3, 2017 at 12:37
  • 3
    Any C# dev who is not able to use VB.Net in a few days using a cheat sheet like this one is probably not worth hiring. So IMHO there is no point in converting any of the existing applications - definitely not for recruiting issues.
    – Doc Brown
    Apr 3, 2017 at 12:44
  • 3
    Unless the recruiting issues are because you can't find devs willing to work in VB.Net.
    – 17 of 26
    Apr 3, 2017 at 12:51
  • 4
    @17of26: IMHO devs who are trying to fight religious wars are even less worth hiring. Note I am not suggesting to stick to VB.NET with any new code, in the given situation, I guess there will be plenty of occasions to write C# code even when no conversion is done.
    – Doc Brown
    Apr 3, 2017 at 12:55
  • 4
    It's not even a religious war thing - it's a personal preference thing. I love C#, and I find VB.Net a bit annoying. Given how many jobs I have access to in my area, there's no reason for me to take a job with VB.Net over a job with C#.
    – 17 of 26
    Apr 3, 2017 at 12:57

5 Answers 5


If you currently have VB.NET devs who know C#, I don't think all 20 applications need any rewriting all at once. It's just too much coding, testing, rolling out and for what? Because your next few hires won't understand the code? Don't confuse C# coders who just hate VB with their not being able to understand it at all or with little training.

I would do the following:

  1. New apps get coded in C#.
  2. Current apps needing significant changes, get converted to C#.
  3. New hires need to learn some VB even if it is a way to convert code or do minor trouble-shooting. They need to learn the systems anyway. They're not going to handle production code on day one. Have a plan to on board them. If they have contempt for VB, it's a great incentive to get it converted. If there are any new projects that are not too large, they could be involved in those. VB dev is just a part of their job for a limited amount of time. Don't let them feel stuck forever.
  4. Determine apps that probably never need to be converted. This may change over time. Make sure this is enough for current team to handle. You may have some apps get phased-out.

A long-term plan where you address things as needed and convert in smaller chunks won't seem like such an over-whelming project. Bringing on 3 new devs is a major task. Don't convert code just for the sake of converting it. You may have apps no one will ever look at again.

  • 3
    This answer goes definitely into the right direction, so +1, but I would put much more emphasis on "Don't convert code just for the sake of converting it". For example, in step 2, I miss a suggestion like "try if the changes can be written inside a separate C#-DLL, so one can avoid any pointless conversion of the existing VB.NET parts".
    – Doc Brown
    Apr 3, 2017 at 12:49
  • 2
    When you get to converting a specific app at least look at the code that is generated by compiling the VB.net code and decompiling it back to C# if you have object oriented VB.net code and aren't using one or two specific features that don't convert well it comes out as reasonable C# code. Refactoring working C# code is easier than converting it all by hand.
    – Sign
    Apr 3, 2017 at 13:26
  • 1
    +1 for "Don't convert code just for the sake of converting it. You may have apps no one will ever look at again.". Also, +1 for @DocBrown comment. It's a good/successful approach which I've used in a few projects in the past.
    – Machado
    Apr 3, 2017 at 13:47
  • Also, it's fairly trivial for a C# programmer to at least understand VB.NET code. If they can't understand it, don't even let them through the door.
    – BgrWorker
    Apr 6, 2017 at 9:55
  • @BgrWorker - Many C# programmers would rather cut off their arm than deal with VB, but you're right, it's not due to any complexity.
    – JeffO
    Apr 13, 2017 at 16:45

Instead of trying to tell you what you should do, I'll share what we did.

  1. Tests get written in C#, because, let's be honest, the VB codebase doesn't have any.
  2. New classes are written in C# inside new class library projects added to the solution(s).
  3. Small modifications to existing VB code are maintained in VB, but characterization tests are added before any modifications are made.
  4. Ruthlessly refactor.
  5. Once you've got significant test coverage, you can choose to migrate VB classes to your new libraries whenever it's convenient, a little at a time.
  6. Retire as many apps / as much functionality as possible.
  7. Don't touch any code unless you have an actual requirement from a user to do so. (There's a concept in Lean Manufacturing, don't do anything until a customer gives you a reason to do so. It'll treat you well here.)

Sooner or later, you'll have very little VB left in a project and good enough test coverage to "finish it off" and rewrite the thin GUI layer. Give it a nice facelift while you're at it. This approach worked extremely well for my team.

Will some of that VB code still be there in 2 decades? Yeah, but it doesn't matter if no one ever needs to change it. Be respectful of your employer's money. Rewrites rarely go well. If you're not concerned about the company's money, then consider your bonus....

  • 1
    This should be the accepted answer. Though JeffO's answer is not bad overall, his bullet point 2 is still too rewrite-friendly. But I guess the OP is not willing to take this warning seriously and will most probably learn it the hard way.
    – Doc Brown
    Apr 4, 2017 at 20:12
  • 1
    @Doc Brown - I guess I wasn't that worried about that point because our existing VB base is split into deep namespaces and has clear separation of entities, business and data logic that means we only ever have to convert functionality from small projects. My expectation is that we will mark existing logic as obsolete and build new logic and any logic that needs updating in new C# project files. In our circumstances, both answers are therefore right, though I appreciate this wouldn't necessarily apply to all. If I could mark both, I would. Apr 5, 2017 at 7:10

The question (for clarity, as it seems some couldn't read the question in its entirety): What is the best approach for migrating a team from VB.Net to C# with all of the considerations above?

Migrating a team is a problem, migrating an existing codebase is another.

Regarding your codebase, @JeffO's answer is a really good one.

Regarding your team, since your current team is already comfortable with C#, I don't see much problems, but please note that C# may have some different conventions than VB.Net, and, while they share the same framework, developers that come with VB6 background usually have different standards than developers that come with C/C++/Java background.

For comparison purposes: C# Coding Conventions versus VB.Net Coding Conventions.

If you're expecting to hire more seasoned C# developers and you want to keep them in your team, it'd be nice to favor the adoption of the C# conventions among your current team while working with new codebase or refactoring old codebase. It's a matter of culture, which sometimes is hard to change in a well stabilished team.

  • Thanks for the resources. I managed to find the little red arrow next to your response. Apr 3, 2017 at 14:07
  • Good points. Depending on the quality or design of the VB code, the new C# devs may not feel it is OOP enough and will create a holy-war beyond the language of choice.
    – JeffO
    Apr 3, 2017 at 15:02

C# and VB.Net are pretty similar languages, but you still want to reduce the risk as much as possible.

There are tools which can perform the translation semi-automatically.

You should do it one project at a time, since a project is the smallest unit you can translate. This reduces risk and will give you a good idea of how much time it will take, what problems you will encounter and so on.

You should not outsource the translation or hire a dedicated developer for the translation. Rather the developers which are already familiar with the code should perform the translation. Since they already know both languages, this will ensure a smooth transition and they will be familiar with the translated code.

Do not attempt a refactoring or restructuring of the code in the same pass. Translate 1:1 even if this means writing "VB in C#", relying on the Microsoft.VisualBasic assembly and so on. You want to ensure the translation succeeded without problems, before you start rewriting in a more idiomatic C# style.


Machado's answer already points to coding conventions and culture. I'd like to emphasize that a C# developer who does not want to work on VB code will not be satisfied with VB converted to "C#" which actually still is VB.

Make sure that your team understands - and lives - the concepts of object-orientation. Do they place the code where it belongs to? Do they separate concerns (e.g. UI and business logic)? Do they understand SOLID? Do they understand how to have objects interact (design patterns, dependency inversion)? Etc.

True there are many C# developers who don't know that either, and it will be important for you to find that out during the interviews. But those who know those concepts might want to leave you soon if nobody else observes them.

Well, you could read that the other way round: find the C# developers who don't know these concepts, and stay with what is said to be typical VB code (though it was "converted" to C#)...

  • 1
    Based on this answer, I'd say that our current VB code base was far from typical. It utilises everything you might hope for with regards to structure and OOP. I don't understand this idea of "typical VB code". Is the assumption that VB developers write entire applications in single code blocks with no signs of OOP in sight? Apr 4, 2017 at 13:20
  • @aaroncatlin From my experience, not quite as bad as single code blocks, but I've seen little separation of forms from business logic, grids connected to a dataset (and that directly to db) instead of a business object, etc.
    – SeraM
    Apr 4, 2017 at 19:16
  • 1
    @aaroncatlin Of course it is possible to write clean object-oriented code in VB. Feel lucky that you have such a great team. Now scrutinize the job candidates that also they have that knowledge, instead of being superstitious because of their language preference. When you advertise the job with those keywords, C# developers should be more comfortable with sometimes maintaining such code which is still in VB. Apr 5, 2017 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.