Best Strategy for moving from VB6 to .NET

Question

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.

Answer 1

I would start with Microsoft's tools:

http://msdn.microsoft.com/en-us/library/aa480541.aspx

Answer 2

See this:
http://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

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.

Answer 3

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 VB.net 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.

Answer 4

You might find the following article useful: http://www.vsj.co.uk/articles/display.asp?id=756

Answer 5

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.

Answer 6

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.

Answer 7

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