asp:feature
LANGUAGES: VB
ASP.NET VERSIONS: ALL
Migration Confrontation
Face the Challenge of Migrating Your VB6 Applications
By Alvin Bruney
Why are we still talking about VB6 today? Because Gartner estimates that 14 billion lines of VB6 code are still in use today. The associated 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 probably on .NET 3.5 SP1. However, the problem is real and it comes with an enormous price tag.
In this article, I want to talk specifically about the migration challenges I have faced at the enterprise level. I ll frame the discussion specifically around large applications (> 1,000,000 lines of code per application) that are complex in nature.
Reasons for Migration
You don t have to migrate your application. You can choose to simply let your VB6 application run as is. However, that approach is only recommended when:
- Your application is feature complete.
- Your maintenance cycle is infrequent in nature.
- You don t have immediate plans to invest in future Microsoft operating systems.
Start a discussion with your technology and business partners about the long-term plans for the application it will help shape your migration decision.
The Cost of Migration
The Gartner cost estimate previously quoted implies that the cost of conversion is less than $1.00 per line of code (LOC). This is reasonably 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 figure moves upward. $10.00 to $15.00 per LOC is not uncommon, especially if the application integrates with other systems (non-Windows, mainframe, distributed COM, etc.), where documentation is sparse and the subject matter experts who understand 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 what stakeholders like to hear, but I ve found out the hard way that it is a real-world picture. When you are done with the conversion project, divide the total spend by the number of lines of code so you can track the cost per LOC for your organization. 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 code per 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 mileage may vary depending on complexity, developer skill set, software development lifecycle maturity, and the availability of upper-end automation tools.
The VB6 Migration Wizard
Automation is the key to containing cost. If your budget allows it, upgrade to the Visual Basic Upgrade Companion from ArtinSoft. The standard migration wizard (also developed by ArtinSoft) included in Visual Studio performs a bare-bones migration that requires more effort from the developer. Exact costs are located on the ArtinSoft Web site (http://www.artinsoft.com), but expect to pay 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 two or more sweeps. Each sweep should be focused on a particular goal. For instance, one sweep should focus on compilation bugs, another on data conversion followed by exception handling, and so on. That way, you can keep track of the length of time it takes for each phase. At project completion, you then can use that information to fine-tune your migration machinery.
Application Inventory
You ll also need to inventory the third-party assemblies that are packaged with the system. Then, allocate some time to hunt down the vendor. 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 a new 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 the binaries in production; maybe the vendor is no longer around, or there is no equivalent 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 simply decides to get up and walk out the door, telling no one of its departure. You usually find this out the hard way only when the QA phase begins and bugs crop up that require repair.
You ll also need to figure out a way of matching the source code that you have with the binaries in production. Do not assume that what you are looking at in your Source Control Manager was used to build the binaries in production. That situation arises when there is inappropriate discipline 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 whatever you have in production to figure out the business logic so that it can be migrated to .NET. You cannot simply Interop to the binaries. You must convert the components to .NET. Get it done, otherwise it will bite you when you upgrade your operating system.
Technical Issues
Plan and buffer for about 10 percent of time dedicated to resolving thorny technical issues. These issues may torpedo the entire project if you are caught unprepared. For instance, some VB6 legacy applications use Dynamic Data Exchange (DDE) for data exchange with Excel spreadsheets. ASP.NET and Windows Forms have no native equivalent. One possible solution requires Visual Studio Tools for Office, but such an option was most probably not in your original migration estimation and will likely increase the spend for the migration effort.
Unit Testing
Do not migrate large applications without a suite of critical test cases and a plan to bake unit test cases in to the migrated application. Critical test cases help you achieve functional equivalence. Unit tests significantly reduce the cost of regression.
It s also a good idea to have a suite of test cases devoted solely to performance, whether or not the original application runs under performance and time constraints. These types of test cases remove the human factor from migration expectations QA s perception of a slow Web page may be different than the developer s expectation.
Outsourcing versus Organic Sourcing
If the application is outsourcable (you ll know what this means from your organization s perspective), outsource the work. Otherwise, staff up and plan for the extra burden that a long project extracts on a development team. Expect lots of frustration and plan for the possibility of key staff quitting.
A word to the wise: Do not be na ve about outsourcing. You get what you put in to the effort (and sometimes less). By that I mean you ll need a system in place to ensure that the migrated code follows your organization s best practices and coding guidelines. You cannot assume that your best practices are the same as theirs (especially across continents). Handing over a guideline document to a vendor and expecting full compliance is an approach that is immature at best. You need to proactively monitor compliance.
You ll also need a governance piece in place so you can escalate issues appropriately, and to the right levels, so that time is not lost 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 or not 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 some tools 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 a migration if there is no value-add. However, the cost of a rewrite is usually more than a migration approach. You need a good strategy to compare the two so you can direct your spend at the best approach. Use the VB6 migration assessment 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 are valid approaches, depending on the scenario.
Also consider assessing a rewrite decision to see if you can first migrate the code, then add features later. For instance, a rewrite may 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 cost significantly less than $700,000. The cost savings justifies a migrate-first approach, followed by feature-add later.
I understand this is not conventional advice; however, it makes sense from a costing perspective for the business. Your technical staff should be able to implement this in a way that is technically sound. Your aim is 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 goals for the application. For instance, if you plan to rework the application so that it caters to a service-oriented approach (especially for Web applications), then your feature-add may significantly increase the effort because it will involve a major re-architecture. This can invalidate the cost benefit.
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 stay on Windows XP, for instance, you are covered until 2012 when mainstream support ends for the Windows XP operating system. There are currently no plans to support VB6 on Windows 7.
There also is custom (read paid) support available for VB6. You should interpret this as a support option designed to be financially unpleasant. There is no publicly available link that I know of that describes exactly what custom support entails it is custom support for a reason! However, it is much cheaper to convert your application today than to subscribe to custom support.
So, why are we still talking about VB6 today?
Alvin Bruney is a Technology Specialist working for Royal Bank of Canada in the .NET Centre of Excellence program. He is a Microsoft Press author and a long-time ASP.NET MVP.
