Migration Confrontation

asp:feature

LANGUAGES: VB

ASP.NETVERSIONS: ALL

Migration Confrontation

Face the Challenge of Migrating Your VB6 Applications

By Alvin Bruney

Why are we still talking about VB6 today? Because Gartnerestimates that 14 billion lines of VB6 code are still in use today. Theassociated migration cost is estimated at $11 billion. Yes, billion. If you work in a small company,you probably won t feel sympathetic; all your legacy applications are probablyon .NET 3.5 SP1. However, the problem is real and it comes with an enormousprice tag.

In this article, I want to talk specifically about themigration challenges I have faced at the enterprise level. I ll frame thediscussion specifically around large applications (> 1,000,000 lines of codeper application) that are complex in nature.

Reasons for Migration

You don t have to migrate your application. You can chooseto simply let your VB6 application run as is. However, that approach is onlyrecommended when:

Start a discussion with your technology and businesspartners about the long-term plans for the application it will help shapeyour migration decision.

The Cost of Migration

The Gartner cost estimate previously quoted implies thatthe cost of conversion is less than $1.00 per line of code (LOC). This isreasonably accurate for all VB6 applications. However, for large applications,the real-world cost falls somewhere between $3.00 and $7.00 per LOC.

The more complex your application, the more this figuremoves upward. $10.00 to $15.00 per LOC is not uncommon, especially if theapplication integrates with other systems (non-Windows, mainframe, distributedCOM, etc.), where documentation is sparse and the subject matter experts whounderstand the intricacies of the system are no longer available.

A large part of this cost is the QA process; large,critical applications require extended and thorough test cycles. It s not whatstakeholders like to hear, but I ve found out the hard way that it is a real-worldpicture. When you are done with the conversion project, divide the total spendby the number of lines of code so you can track the cost per LOC for yourorganization. Trust me, this will help you in other VB migration efforts.

The Pace of Migration

Expect to convert between 10,000 and 12,000 lines of codeper week. Anything more than 12,000 lines of code is a challenge to maintain,especially after you factor in the numerous issues that crop up. Your mileagemay vary depending on complexity, developer skill set, software development lifecyclematurity, and the availability of upper-end automation tools.

The VB6 Migration Wizard

Automation is the key to containing cost. If your budgetallows it, upgrade to the Visual Basic Upgrade Companion from ArtinSoft. Thestandard migration wizard (also developed by ArtinSoft) included in VisualStudio performs a bare-bones migration that requires more effort from thedeveloper. Exact costs are located on the ArtinSoft Web site (http://www.artinsoft.com), but expect topay north of $10,000.

That said, automated tools can only take you so far.Eventually, you ll have to get out and push. Organize your manual effort in twoor more sweeps. Each sweep should be focused on a particular goal. Forinstance, one sweep should focus on compilation bugs, another on dataconversion followed by exception handling, and so on. That way, you can keeptrack of the length of time it takes for each phase. At project completion, youthen can use that information to fine-tune your migration machinery.

Application Inventory

You ll also need to inventory the third-party assembliesthat are packaged with the system. Then, allocate some time to hunt down thevendor. Budget additional time for converting all of these assemblies to .NET.If you don t perform this step, your application may fail when you upgrade to anew operating system that doesn t contain the VB6 runtime. The task is non-trivial.Typically, the source code is not available, or it is out of sync with thebinaries in production; maybe the vendor is no longer around, or there is noequivalent component available today.

Source Code Archiving

Make sure all the updated source code is available to you.This is often not the case for large applications. Often, source code simplydecides to get up and walk out the door, telling no one of its departure. You usuallyfind this out the hard way only when the QA phase begins and bugs crop upthat require repair.

You ll also need to figure out a way of matching thesource code that you have with the binaries in production. Do not assume thatwhat you are looking at in your Source Control Manager was used to build thebinaries in production. That situation arises when there is inappropriatediscipline to the source control policies or immature versioning processes.

For source code that does not mirror production binaries,you ll need to decompile the production binaries or reverse engineer whateveryou have in production to figure out the business logic so that it can bemigrated to .NET. You cannot simply Interop to the binaries. You must convertthe components to .NET. Get it done, otherwise it will bite you when youupgrade your operating system.

Technical Issues

Plan and buffer for about 10 percent of time dedicated toresolving thorny technical issues. These issues may torpedo the entire projectif you are caught unprepared. For instance, some VB6 legacy applications useDynamic Data Exchange (DDE) for data exchange with Excel spreadsheets. ASP.NETand Windows Forms have no native equivalent. One possible solution requiresVisual Studio Tools for Office, but such an option was most probably not inyour original migration estimation and will likely increase the spend for themigration effort.

Unit Testing

Do not migrate large applications without a suite ofcritical test cases and a plan to bake unit test cases in to the migrated application.Critical test cases help you achieve functional equivalence. Unit testssignificantly reduce the cost of regression.

It s also a good idea to have a suite of test casesdevoted solely to performance, whether or not the original application runs underperformance and time constraints. These types of test cases remove the humanfactor from migration expectations QA s perception of a slow Web page may bedifferent than the developer s expectation.

Outsourcing versus Organic Sourcing

If the application is outsourcable (you ll know what thismeans from your organization s perspective), outsource the work. Otherwise,staff up and plan for the extra burden that a long project extracts on adevelopment team. Expect lots of frustration and plan for the possibility ofkey staff quitting.

A word to the wise: Do not be na ve about outsourcing. Youget what you put in to the effort (and sometimes less). By that I mean you llneed a system in place to ensure that the migrated code follows yourorganization s best practices and coding guidelines. You cannot assume thatyour best practices are the same as theirs (especially across continents).Handing over a guideline document to a vendor and expecting full compliance isan approach that is immature at best. You need to proactively monitorcompliance.

You ll also need a governance piece in place so you canescalate issues appropriately, and to the right levels, so that time is notlost unnecessarily in a wheel spin. Wheel spins cost your organization money and the cost increases across time-zone boundaries.

VB versus C#

Language wars aside, you ll need to determine whether ornot you want to migrate to C#. The migration tool takes you to VB.NET only.There is effort and cost involved in moving from VB.NET to C#. There are sometools on the market that help, such as Instant C# from http://www.tangiblesoftwaresolutions.com,but there is still effort involved.

Rewrite versus Migration

It s very difficult to convince the business to pay for amigration if there is no value-add. However, the cost of a rewrite is usuallymore than a migration approach. You need a good strategy to compare the two soyou can direct your spend at the best approach. Use the VB6 migrationassessment tool (available at http://www.microsoft.com/downloads/details.aspx?FamilyId=10C491A2-FC67-4509-BC10-60C5C039A272&displaylang=en)to help you determine if you need to migrate, rewrite, or leave as is. All arevalid approaches, depending on the scenario.

Also consider assessing a rewrite decision to see if youcan first migrate the code, then add features later. For instance, a rewritemay cost one million dollars end to end. However, a migration effort may cost$300,000. It s very likely that the addition of new features will costsignificantly less than $700,000. The cost savings justifies a migrate-firstapproach, followed by feature-add later.

I understand this is not conventional advice; however, itmakes sense from a costing perspective for the business. Your technical staffshould be able to implement this in a way that is technically sound. Your aimis to achieve functional equivalence without compromising quality. For that,think outside the box to reduce cost.

Be careful to weigh this decision with the long-term goalsfor the application. For instance, if you plan to rework the application sothat it caters to a service-oriented approach (especially for Webapplications), then your feature-add may significantly increase the effortbecause it will involve a major re-architecture. This can invalidate the costbenefit.

Support Options

From a support perspective (http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx),the VB6 runtime is tied directly to the operating system. If you plan to stayon Windows XP, for instance, you are covered until 2012 when mainstreamsupport ends for the Windows XP operating system. There are currently no plansto support VB6 on Windows 7.

There also is custom (read paid) support available for VB6. You should interpret this as asupport option designed to be financially unpleasant. There is no publiclyavailable link that I know of that describes exactly what custom supportentails it is custom support for a reason! However, it is much cheaper toconvert your application today than to subscribe to custom support.

So, why are we still talking about VB6 today?

Alvin Bruney is aTechnology Specialist working for Royal Bank of Canada in the .NET Centre ofExcellence program. He is a Microsoft Press author and a long-time ASP.NET MVP.