My company has tons of legacy applications that are written in VB6.

We are in transitions from moving VB6 applications to .NET (3.5 specifically).

What would be the best strategy for moving form VB6 to .NET?

NOTE: Below update should go to "Project Management" and has nothing to do with the main question.

[UPDATE]: Thank you for your feedback so far
Now there are more question that pop up are

  1. how would you assign developers to develop new applications?
  2. Should there be a special one-time upgrade division that will convert legacy apps to new ones? Or should every developer participate on conversion process?
  3. Should only senior developers participate on conversion? Junior developers? or mixed?

It seems like, the more I think about this problem, more questions just show up.

+1  A: 

I would start with Microsoft's tools:

I wasn't even aware that there was even such a guideline on MSDN...
Sung Meister
The Microsoft tool is pathetic - according to the guy who wrote it. A better Microsoft article is this recent one from Microsoft UK
+2  A: 

See this:

Of course, C# vs VB.Net is just one part of it.

For example, another thing to consider are if you want to use this opportunity to move these apps to an intranet, if you haven't already. Or how deep do you want to delve into microsoft's stack. Is Winforms enough or do you want to use WPF, for example.

Joel Coehoorn
+5  A: 

Clearly this is a major undertaking which will involve lots of work.
So my advise would be to treat it like a very long term project.

Have a clear goal in mind, which addresses major issues like security, resilience, maintainability and the future of your applications.

Once this has been agreed by the stake holders, develop a prototype system to test your assumptions with, where you can try out C# vrs or MVC vrs Webforms. I would assign your best developers for this.

Then start with one your small legacy systems, and build the core components which you will re-use in other areas.
At this stage, start with your more senior developers, but everyone must get involved and be familiar with the new framework.
This will ensure everyone is trained at the same time, and no one is left behind.
Depending on how many applications you have I would rotate developers, so all systems can benefit.

Also all new work must be done in your .net language not in VB6.

Gradually convert each one of your legacy applications. (I would only convert them if they are changing or if there is a clear benefit to updating them.)

This should give you a solid framework to use going forward, while still ensuring users functionality isn't hindered by your migration.

For example:
I've worked at a company which had roughly 40 or so VB applications.
Over time we have migrated all of these to C# and now (5 years later), we have roughly 150 c# applications (all in .net 2.).

These all share a common framework, making them easy to maintain, and extend where necessary.

Now, this "For example" paragraph brought me another question (question is updated)
Sung Meister
Updated. You might want to split these out into sub questions.Although these are leading away from development, and towards project management.
@Bravax: You are completely right. I should keep development away from project management.
Sung Meister
+1 for answering from actual experience! I'm curious. Did you rewrite your applications or migrate them automatically with a tool like Artinsoft's? If it was a rewrite, did you consider using the tools? What were the pros and cons in your view?
We rewrote them. The pros was complete integration with the new framework, which makes mainteance now much easier. The cons are the length of time it took, but to be honest we didn't rush at all, and our users didn't notice this upgrade. (Apart from new functionality they got.)
To be honest the codebase was in such a dire state, I wouldn't have used a tool to upgrade it.
Interesting. Microsoft rarely recommend rewriting: for instance the following situations. Really bad architecture in original app. OR original app no longer meets business needs. OR core change required, e.g. desktop app to web app. OR you already have significant .NET skills and app is small.
.. obviously you can always think of improvements in any architecture. I think they mean when it's really causing extreme problems that can't be gradually overcome by incremental refactoring.
It's impossible to generalize, and say never rewrite. It can be the best case, it really depends on your circumstances.
Oh, sure, never say "never". But they do say "rarely recommended". Your situation now sounds ideal - I'm jealous - and your users/management haven't complained, so it was obviously right for you. Anyway I'm sure that's more than enough comments from me!
You seem to prefer a particular approach, and have answered numerous questions in this area, so this may be your speciality. Your answers are definately worth reading for anyone engaged in his problem.
+1  A: 

You might find the following article useful:

That article looks up-to-date and comprehensive. Thank you
Sung Meister
+4  A: 

Try replacing core functionality with COM enabled .NET libraries. "Hollow out" your existing VB6 apps by moving functionality to .NET bit by bit.

Beware of complete rewrites. Though they are tempting "because it is a clean cut" - usually madness lays ahead! Read "Working Effectively with Legacy Code" by Michael Feathers as a preparation. Though the book does not specifically go into "moving from one language to another" it does show a lot of real world pitfalls you will encounter.

I do think that all developer should have defined time slots where they do migration work on the legacy apps they developed before. Since they already have domain knowledge and know the problem space they should be the most productive.

I found that an incredibly difficult book to read.
Dun3: Are you suggesting that answer because you've done it, or because it seems like it should work?I've been in places where that was done, and the result was that COM Interop (which is heaps slower with .NET) became the limiting performance bottleneck.
@Arafangion - yeah, I have done that. And I do agree though - one really has to understand the performance implications of the "slicing". The same rules as using a webservice apply though. Avoid chatty interfaces and it should rarely be a problem.
+2  A: 

Here is an adaptation of my answer to a similar question.

Converting large programs automatically is a better choice than rewriting. It's a common pitfall to start out optimistically rewriting a large piece of software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.

...and here's a blog post by a Microsofty that agrees with me:

Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large

This excellent Microsoft page recommends two third party migration tools as better than the underpowered built-in VB.NET upgrade wizard - Artinsoft and CodeArchitects VBMigration. Artinsoft wrote the built in VB.NET upgrade wizard, this is their improved version. And CodeArchitects was founded by Francesco Balena, who wrote some of the classic books on VB6 and VB.NET.

The same Microsoft page also says:

Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.

EDIT: Sung says in the comments: "I am not a big fan of auto generation of code because it is harder to debug initially and might take just as long as it takes to rewrite whole thing". I have to disagree strongly. In general I too am no fan of code generation, but in this case the resulting code will be structured identically to your original VB6 and should be almost totally functional. I haven't actually tried these tools myself yet, but from their customer testimonials this promise is fulfilled.

And I repeat the Microsoft advice just above, based on their experience of assisting many migrations - "a complete rewrite is far more costly and difficult than converting [my emphasis]" - a flat contradiction of the supposition that it might take the same time. If you want to improve the structure of the VB6, migration then gradual refactoring is likely to be far more cost effective than a rewrite.

I am not a big fan of auto generation of code because it is harder to debug initially and might take just as long as it takes to rewrite whole thing; My rule of thumb is that debugging takes 1.5~2 longer than writing actual code; I am inclined to go with writing smaller modules first and move on.
Sung Meister
This is automatic alteration of existing code rather than automatic generation of code, which I agree can be a nuisance. And the process takes much less time than rewriting, according to Microsoft's digest of their customers experience. One important consideration: do you have tests for the code.

VBDepend can help to understand the existing vb6 code before migration, and accelerate the process during migration.

Hi, Issam. would you provide a link to VBDepend product site?
Sung Meister