How do you migrate a large app from VB6 to VB .net ?

Question

My company makes a monolithic piece of software that our customers use to run their car dealerships. The original app was written in VB6, and it has grown substantially over the last few years. Until now, there hasn't really been a business case for switching to the .net framework. Sure, it's newer, considerably better at certain things, and when used correctly speeds development time, but there's nothing we can't do in VB6 that we need to be able to do. Getting things done is harder in VB6, but almost nothing is impossible. Recently though, Microsoft dropped support for VB6, and it seems obvious to me that switching to a new platform is inevitable.

The way VB .net works and requires you to think is so fundamentally different (heck, even the way you pass variables into subs has changed), and as far as I can tell, switching to .net would require a complete re-design and re-write of the app.

My question(s): Have any of you been in this position? Of the tools available to smooth the transition, which ones work and which should be avoided? And how do I sell our customers and my boss on this? As the suits like to say, where's the ROI?

Answer 1

Okay... large app... but are we talking a whole boatload of WinForms and some ADO code for DB access or does it include a heap of ASP web pages as well as some custom commercial controls you bought 7 years ago? What's the installed base? Support from Microsoft is gone, and although that sounds dramatic, how many times did Microsoft themselves provide you with support in the last 24 months?

Answer 2

@Rob Burke:
Boatload of WinForms: Absolutely.
ADO code for DB access: Yes, but all in one easy-to-manage place.
ASP web pages: None. This is strictly a desktop app.
Custom controls: Yes, but all written by us (i.e. no third party stuff).
Installed base: ~1000 machines.

Last time I called Microsoft tech support (I would have been 16 or 17 at the time), I was having trouble getting the MSDN library to work on my machine (this is back in the days when MSDN wasn't available online, and internet connections were dial-up). After having my support case elevated, the "solution" they gave me was to format my hard drive and reinstall everything. Needless to say, I didn't consider that a solution.

Answer 3

I've run across a similar problem in my company and have unfortunately found no easy and good way of migrating from VB6 to .Net. In fact, when I went down this path a few months ago, every road led me to the same conclusion: they're just too different of platforms, and I'd be better off treating it as a literal rebuild of the application than thinking of it as a migration.

I know this is probably not an acceptable solution in most companies (which is why we still have a lot of stuff hanging around in VB6), so all that said I know that Microsoft has an Upgrade Wizard, which I only looked into far enough to discount it as a reasonable option. There may be other options out there, but I'd guess that they're plagued by the same issues in the MS Upgrade Wizard.

If you're interested, the article that convinced me not to bother is here.

Is there a reasonable way you can rebuild part of the app, and leave the rest as COM DLLs until you can rebuild more of the application?

The situation just kind of sucks. The best I can say is here's how I ended up handling it: I was able to use the fading platform support as a way of highlighting the application's other deficiencies and got an actual, honest-to-god new version of the application on the roadmap. At the least, we were able to use it as an opportunity to improve our solution.

...and then we hired a third party company to develop a different solution and didn't complain when they started delivering in VB6. Sigh.

Eric Sipple

Answer 4

I agree with Eric's statement that you have to treat VB6 and .Net as completely different platforms. You will have no easy way to port your logic over in a way that will ultimately save you time and not keep you shackled to the deficiencies of VB6.

In terms of ROI: make a list of all of the support tasks that you have made in the past year, and estimate how much of a time savings they would have been if you were working with a well-structured .Net App vs. your old VB6 dinosaur. This is your yearly support savings. Then if you have any big upgrades coming up, figure these in as well. Are there any proposed new features or upgrades that have been rejected because they were too hard in VB6, but that would be doable in .Net? If there are big features coming up or that you would like to include, then you could see a good ROI for going to .Net. If the program is basically stagnant and there are no plans to change the status quo, then you probably wont get the buy in that you need.

Answer 5

I went through this process about 18 months ago. We had a lot of VB6 code that needed to be ported to .net.

Our code was a collection of EXEs and DLLs in several different projects, so I was able to tackle each project individually. I used the Visual Studio VB migration tool to do an intial conversion to VB.Net. I then needed to do a lot of cleaning up to get the software to compile.

Gradually, each project was converted and we could say goodbye to VB6.

The great thing is that all our code runs on .Net now, so the VB integrates very nicely with other projects we had written in C#. We had lots of functionality duplicated in C# and VB6, so now everything uses the C# code.

We also get to use Visual Studio 2008 which is much, much nicer and more productive than the VB6 IDE. Hey - it even has mousewheel support.

The downsides: Using the migration tool means that we've got .Net code but with the structure of a VB6 program. It is not at all what you'd write if you were starting out from scratch in VB.Net. We're gradually refactoring the VB6-ness out.

Still, I think that using the migration tool was a quicker and more reliable process than rewriting from scratch.

It was all a fairly labour intensive process. Several months work to produce software that looked and behaved exactly the same as the VB6 version. But since then updating and maintaining the code has been a breeze and well worth the investment.

Answer 6

By "monolithic piece of software" I assume you mean it is all in a single project?

You might find it easier to split sections of functionality into smaller DLLs before starting a port. You can than tackle smaller sections at a time.

You might be able to convince your boss to let you port a small portion of the software as a trial. If that works out well you can move on to the rest of it. If it's a complete failure then you haven't wasted too much time.

Answer 7

+1 for Yaakov's points on estimating Return on Investment.

Also, there are a couple of 3rd party tools for vb6->.net conversion. I've not tried any of them (nor am I associated with any of them) but the one below is from a well known VB book author so seems like it might be promising:

http://www.vbmigration.com/

Answer 8

I've been active in a large German VB community for years now and the consensus of all (!) people who have talked about this on our platform was “don't.”

Some of the hints in previous answers have been pretty good and I would advise you to follow them and try porting the project but at the same time I advise against premature optimism. In the whole, the conversion assistent seems to do a decent job if the project isn't too big and you don't intend to tread the codebase as an active asset (i.e. you intend to extend and change it).

As soon as this isn't the case any more, a complete rewrite will be in order. I wouldn't even bother trying to transfer any parts of the old application, because from my experience and all that I've heard this will invariably be more expensive than rewriting from scratch.

Answer 9

I'm oldschool and like to have a big bookshelf full of coding books, so I can reccomend this book from actually reading it:

http://www.amazon.com/Upgrading-Microsoft-Visual-accompanying-CD-ROM/dp/073561587X/ref=sr_1_1?ie=UTF8&s=books&qid=1220718918&sr=1-1

It covers all of the common gotcha's that the Upgrade Wizard can't find, such as ADO to ADO.NET Migration, Replacing Control Arrays, ActiveX/COM integration etc.

It also has a great section on .NET technologies that you can use to replace some brittle VB6 technologies (COM+, .NET Remoting, Web Services, A quick rundown on WinForms).

Answer 10

I recommend not converting. When you convert you end up with .NET code that you don't want and would hate to maintain. If you are making minor changes/enhancements I would stick with VB 6. If you are really adding to or significantly changing the feature set then I believe you are better off rewriting the app. At that point you should look at what the best language is to implement your new/redesigned app. VB .Net may be your best choice and it may not.

Answer 11

Have any of you been in this position?
Yes.

And how do I sell our customers and my boss on this?
I will say to them: "It's better to transition to the new technology in a planned manner than have to rush it because the program in no longer supported under Windows 2020 or something. We will have to do it one day or another like it or not".

As the suits like to say, where's the ROI?
You have to tell that with the new port, you will implement features x and y.
If you port to WPF there are some features built in: Resolution independence, better support in terminal server, etc.

Best way to do it IMO
First migrate the business logic, you can take advantage of a real OOP language. You can do it in different stages. Using .net-com interop you can use .net DLL in VB6.
Then start migrating the UI, in stages as well.

Answer 12

My advice: Consider this in a strategic manner, approach it as a rewriting of your existing application from the ground-up. Use this opportunity as a way to deliver whatever significant changes in UI, process or functionality that just haven't been open to consideration with your legacy application.

I would initially set up a seperate team of developers to begin the design and development and consider this release to be like a 2.0 of whatever your legacy application is. Use this new development as a way to deliver the big changes that your customers have wished for for years and deliver that big change in the same manner as Microsoft did with Windows 95.

When Windows 95 was close to shipping, Microsoft began talking to the non-technical public about how much this new platform would revolutionize computing and improve user's lives (blah blah blah). While many of the promises came true, the real lesson is that Microsoft successfully implemented a huge UI / system change into the marketplace by preparing the market for this shift. Microsoft didn't try to market Windows 95 as Windows 3.3 or 4.0...a complete numbering change helped to signal that big changes were afoot, and people were ready to hear and experience the change.

With your rewrite of your application, I'd recommend a similar approach where you prepare for a long development effort, put everything on the table as potential for change and deliver something that truly transforms your user's experience, because by shifting development to .NET you WILL be changing their experience of your application wether you try to or not. (so why not swing for the upper deck?)

Answer 13

The book on upgrading VB6 to VB.NET recommended by Jonathan is useful, but you don't have to buy it - it's available as a free download from Microsoft's web site.

My advice is don't underestimate the effort of conversion - be very cautious about embarking on a rewrite. It's a common pitfall to start out optimistically, 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

EDIT: (added this quote from a new excellent Microsoft webpage).

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.

Also the renowned VB expert Dan Appleman says:

In most cases porting [VB6 to VB.NET] is stupid and a complete waste of money.

And Joel said a while back:

The single worst strategic mistake that any software company can make [is to] decide to rewrite the code from scratch.

A couple of other useful links about migration including links to another free book from Microsoft. One. Two. EDIT: New Microsoft page including screencast with their answer to this question.

And finally, Microsoft have not actually totally dropped support for Visual Basic 6. The runtime is supported on Windows Vista, Windows 7 and Server 2008 for the full support lifetime of those operating systems. See the official Microsoft statement.

Answer 14

We are in exactly the same position. Our monolithic system is in one project because years ago, developers had trouble working with multiple DLLs. We only have three programmers (we should have 4 or 5 but there are no plans for this) and no money for a redevelopment team.

The way we are moving is to move small bits of less-critical functionality at a time, with the intention that we can build on successes with more conversions. Management is unhappy with the speed of moving to .NET. The slowness is caused primarily by 1) my need to recreate so much of the framework that was developed into the VB6 system over the last decade, and 2) my need to create some minimal OO framework for future development.

My suggestions would be to 1) realize the business costs of what you want to do. It is huge - I'm guessing that your customer base is mostly satisfied, but is used to occasional updates. If you were to stop with the updates, they would get restless. Your company is probably charging all the market will bear for your product and while it is enough to make your customers choke, it still isn't enough to keep your company happy. 2) be patient but persistent. 3) read the books linked to - I certainly intend to!

Answer 15

If it is critically important to preserve the behavior your application or if it is mission critical then conversion is the only path.

You need to redesign your monolithic applications so it has a least two layers. The User Interface, and a ActiveX DLL with your business logic. Better yet you have three layers, the UI, the Business Logic DLL, and a your Personal Framework DLL. For database applications the personal framework is often the Database and Reporting API the software is using.

Once you have your application redesigned. You can then rip off the UI and replace it with .NET. Once you have that tested you can then convert the business logic, follow by your personal framework. Luckily both VB6 and and .NET can use COM Components. If you put your business logic and your personal framework in a ActiveX DLL then you can reuse it in .NET.

The reason for this is so BEHAVIOR is PRESERVED. Your users expect the software to work in a certain way. Each intermediate step leaves you with a working piece of software working the same way it did in the past. If isn't then you didn't add enough tests.

It helps to implement unit tests. http://www.nunit.org. This way you make sure that the both VB6 and .NET version produce the same results and behaviors.

I recommend going from the top down as most of value of your application lies in your business logic and your personal framework. Note that a fair amount of people have their UI and business logic considerably mixed. In my company application the UI is a thin shell that calls a ActiveX DLL (not Control) that performs the actual operation. The more thin your UI layer is the easier the conversion.

This involves a lot of extra work over what most people think a conversion process involves. I have done over six major conversions of our company's software. We write CAD/CAM software that controls metal cutting machines. This software has been continually developed since 1983. Originally done in HP's Rocky Mountain Basic on a 300 series workstation is now under the .NET framework running under Windows Vista.

Each time I learned something new about the conversion process. The traditional idea of sitting down and doing a rewrite leads to a situation where it is 90% done after a year and then you chase that last 10% for the next three years.

By doing it methodically by starting with a good design, unit testing, and so on you will have a project that will 100% done in two years instead of a project that mostly done in a year. Note that the time estimates are relative. You have the bonus that each step leaves you with working software. Plus if your approach for the current step is way off base you didn't waste all the work on the previous steps as compared to doing it in one go.

I recommend reading up on refactoring which involves modifying the design of your code in a predictable way. Examples is adding a parameter to a class method or renaming a function. Read up on Desgin Patterns. Design Patterns are to objects as Algorithms are to function and data structures. A good design pattern will tell you how to create a series of object to achieve some commonly done task.

Hope this helps.

Answer 16

Step 1: Rewrite UI frontend in VB .net. This is pretty easy. Even a conversion tool can probably get this mostly right.

Step 2: Rebuild VB6 components as DLL. This is a moderate nuisance, since you need to replace all your UI accesses with hooks that can be called. The difficulty of this step is proportional to how tightly coupled your UI is with your logic. In a pinch, you can leave the UI in place invisibly and have the hooks access the UI...but this is a hack at best.

Step 3: Attach UI frontend to VB6 components. This is somewhat of a nuisance.

At this point, you already have a .Net application, and can rewrite any calls to the VB6 code at will. Also, changes to the VB6 code will appear in your .Net code during the time period where you're still developing both.

Answer 17

I would recommend a complete rewrite - in ASP.NET MVC using c#.

vb.net is not going to go away but its no longer language de jour either. And if you;re rewriting, choose the environment where the most functionality and skills lie.

Get some fresh blood in to set this up for you so that you have best practices defined for you.

Answer 18

You should take a look at what Visual WebGui and Artinsoft has to offer in that field which would allow you to avoid the risk and costs of rewrite and also can bring you all the way to web or even Cloud if that could be a future need.

Basically you should be able to take your VB6 code and after a couple of stages receive a .NET code that can be also used in pure web or cloud environments. More info is available here.

Answer 19

To migrate vb6 code , a tool that help to understand the existing code could be useful, for example VBDepend is a useful to understand the vb6 code base.