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.

Which Applications Should You Migrate?
And if all of that weren’t frustrating enough, there is still a much larger and more abstract task that must be front-loaded onto this whole messy process: deciding which apps to migrate and which to leave as is. Zoufaly tries to put a somewhat tidy bow on that part of the decision making. A migration project, he says, is worthwhile only if the application will use the new functionality in .NET to significant advantage. Consider, he says, only those applications—and indeed portions of applications therein—where “if you move it to .NET and Web enable it where you’re really adding value to your business.” He says these should be “highly visible projects” within the organization. Leave everything else, he says, in VB6.

But that answer strikes me as too simplistic, considering what he told me about the prevalence of macro issues and the incredibly long and tedious migration process for an application of significant size. Assuming a developer has an application that could leverage new features of .NET to great advantage, he or she needs a way to estimate the time and resources required for the migration in order to make a well informed decision—to avoid wasting precious time on a project that will ultimately be abandoned halfway through.

And that, really, is where the murkiness continues. There is no tested methodology for estimating the parameters of a migration effort. You either jump in and be ready with a Plan B in case you have to pull out, or you get the organizational support you need to bring the project to completion regardless of the unseen challenges which might arise. Neither is a comfortable way to begin.

There’s a flip side to all of this of course, which is that however flawed and difficult the migration process might be, the tool provides an invaluable bridge. Zoufaly asserts that the migration wizard ArtinSoft has built will convert a VB6 application in one-tenth to one-twentieth of the time it would take to rewrite it manually. He says that on an average project, it will do 90 percent of the migration work automatically. For those enterprises for which migration is a foregone conclusion, the migration wizard is a treasure.

But developers should also know that stability continues to be an issue. Though Zoufaly says that he feels the product is currently quite robust, the ArtinSoft team is still working on some bug fixes. Zoufaly says that there are “almost no breaking changes.” (Italics are mine.) Further, it will not be until the next version of .NET is released that the entire feature set will be in place. Support for migrating WebClasses and User Controls are not available now, but are the two planned features that will complete the product.

Other ArtinSoft Migration Tools
ArtinSoft has several other .NET migration tools in various stages of completion. The company announced earlier this month two different products under the moniker Java Language Conversion Assistant (JLCA), one of which converts JDK 1.1.4-compliant code to C# (obviously catering to the Visual J++ developer) and another which will migrate J2EE code. The former is available in beta now. The J2EE version is expected in the third quarter.

Zoufaly also promised an ASP to ASP.NET conversion tool that ArtinSoft hopes to release in time for Tech