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.