or all the functional enhancements that .NET brings to a developer's world and the excitement one might be feeling about putting these advances into practice, the truth is that this is not exactly a golden age for Visual Basic 6 developers. If you have a significant VB6 code base that you might like to bring to the .NET platform, the next year to two years promises to bring you a measure of pain the likes of which you've never quite experienced professionally before.

Oh sure, it's fun to dream about Web-enabling all those Windows apps, to imagine deploying this bit and that as a Web service, but getting there is not for the faint of heart. In fact, in the resource-constrained, post-amputation wards that are the majority of corporate America's post-layoff IT departments, it may not be attainable for even the flintiest of souls. Bottom line: if you think—even have a dreamy flicker of hope—that you will be migrating enterprise VB6 apps to .NET you had best start by evaluating your resolve and your resources. You will not succeed without plenty of both.

Five Immutable Migration Truths
Federico Zoufaly is at the center of the .NET migration universe. He is the CTO, General Manager of Microsoft Technologies at ArtinSoft. For nearly two years, he has single-mindedly led his organization in doing the bidding of the .NET product team, creating the "wizards" that Microsoft hopes will assist developers in making the transition to .NET. Microsoft views .NET as the bottomless vessel into which it plans to pour the development world; ArtinSoft is building the funnels.

Microsoft approached ArtinSoft with the migration gauntlet in 2000, Zoufaly said. He boiled those early discussions with Microsoft down to two sentences: First, 'we are breaking backward compatibility in VB.' And second, 'we need a good upgrade story.'

Federico Zoufaly

Zoufaly will not tell you that migrating VB6 to VB.NET is in any way easy. It is not in his nature to lie. He is more of a developer turned executive rather than the other way around. He seems vaguely nonplussed by his newfound stature in the development world. Talking to him last week at VSLive!, he gave a very candid appraisal of the technology his company has created and the challenges which are inherent in migration—both the ones that his tool can solve and the ones that it can't.

A pragmatist, Zoufaly advises that VB developers first accept the following immutable truths:

• you should not attempt migration until after your migration team has studied and learned the .NET environment
• migration, particularly the first time you do it, is going to be very frustrating
• migration is in no way a hands-off process
• some applications simply cannot be migrated automatically
• the only applications worth migrating are those which the company intends to significantly enhance with functionality that only .NET can provide

In other words, if you've imagined a process by which one loads some VB6 code into the wizard, does a few days' worth of debugging and testing, and emerges with a VB.NET application, you are living a fantasy. And the sooner you abandon that fantasy the better off you will be.

Zoufaly advises that developers should expect to spend a minimum of two to three weeks in training on the migration process and using the migration tool in practice before attempting an actual migration. And that is two to three weeks on top of the weeks and months that developers should spend learning VB.NET and the .NET framework.

"I'm not sure that [VB6 developers] realize how much more difficult it is," says Zoufaly. "But they should be able to get it. The best advice I can give is to learn VS.NET first."

After a developer is sufficiently comfortable with .NET and has spent several weeks in studying the migration process with the tool, Zoufaly says that a migration should progress at an average rate of just 7,000 to 10,000 lines of code per week. Therefore, a 1 million-line VB6 application will take 100 weeks—two years—to upgrade. Seems a little slow for something that Microsoft had the hubris to dub a migration "wizard."

Micro and Macro Issues
Zoufaly explains that the types of problems developers will experience during a migration fall into two categories: micro issues and macro issues. Micro issues are the type which generally require a simple replacement of one data type for another and which can be easily fixed in the tool. It will scan the code and display a list of the errors found. The errors are integrated with contextual help, so you can get more information by clicking on any error in the list and pressing F1. You can then tell the tool the appropriate fix for each micro issue and it will automatically replace them for you in a batch. Then it's just a matter of testing and retesting the code.

Macro issues are the ones to fear, as they are not the sort that can be solved with a global replacement in the wizard. These require refactoring of the application to change its reliance on unsupported technologies—before the migration wizard can be of any assistance. You can count on Macro issues arising in code that uses ActiveX documents, graphics, RDO/ADO data binding, and GoSub. If your application uses any of the above, be prepared to spend significant time and labor to refactor your code manually. In the case of ActiveX, you can forget about upgrading at all.

Zoufaly says developers should expect to spend one-third of the total upgrade time in preparing VB6 code for migration. In other words, at least 33 percent of the battle is fought before you stick even the first line of code into the migration wizard. This document will help you see what you'll need to do to prepare your code for the most common upgrade issues.