Microsoft is ending its support for the Visual Basic 6 development tools on 8 April 2008 which leaves some companies in the precarious position of developing business critical applications with no support for their development tooling. Fortunately, the Visual Basic 6.0 runtime is still supported for quite some time:
The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications on Windows® Vista™. The Visual Basic team’s goal is that Visual Basic 6.0 applications that run on Windows XP will also run on Windows Vista. The Visual Basic team is also committed to the Visual Basic 6.0 development environment running on Windows Vista. As detailed in this document, the Visual Basic 6.0 runtime will be supported for the full lifetime of Windows Vista, which is five years of mainstream support followed by five years of extended support (Source).
Microsoft will support the VB6 runtime for the full lifetime of Vista (2017) and will continue to support Windows 2000, Windows XP and Windows 2003 for the support lifetime of these operating systems [Hammond]. This leaves companies with a 10 year window in which to migrate their VB6 code. After 2 April 2008, the only way to obtain support for the VB6 IDE will be through a custom support contract. These custom support contracts will typically be very expensive and do not cover support for any third party controls being used in the applications [Hammond].
In this article I attempt to summarize some of the different strategies, best practices and options available that I have found when investigating what route to follow with our existing Visual Basic 6.0 code bases. The article starts off by looking at different Migration Strategies that help you prioritise and identify when and how to migrate your applications. It then proceeds to look at some Migration Best Practices and pitfalls. Migration Options, like external vendors and hybrid solutions using .NET and VB6 are considered next. The article closes off by providing Additional Resources to further explore the topic.
References
The following references were used in writing this article:
- [Driver] Driver, Mark. Visual Basic 6: Setting End-of-Life Migration Priorities. Gartner Research, Inc.
- [Hammond] Hammond, Jeffrey. Keys to Successful VB 6 Migration. Forrester Research, Inc.
- [MSPP] Microsoft Patterns + Practices. Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005. Microsoft Ltd.
Migration Strategies
Source: [p10, MSPP]
Microsoft [MSPP] presents the following criteria and list of key indicators (summarized graphically above) for deciding when and how to upgrade an application:
- Low value, low quality = Replace
- Out of line with business needs
- Time, cost, disruption of replacing application is acceptable
- Can change business model to fit an off-the-shelf application
- Low value, high quality = Reuse
- Low operational costs
- Business rules are satisfactory
- Sufficient resources to maintain legacy code
- Possible to rely on 3rd party support
- High value, low quality = Rewrite
- Off-the-shelve software do not meet business needs
- Time, cost, disruption of rewriting application is acceptable
- High maintenance costs
- Poor quality code
- Business rules are satisfactory but you will need to add functionality to the application
- High value, high quality = Upgrade/Migrate
- Good fit to business needs - require only moderate functionality changes
- Requires only moderate functionality changes
- Future vision includes web services/SOA architecture
- High operational costs for existing solution
- Difficult and costly to find resources to maintain existing application
- Necessary to upgrade to support .NET for strategic reasons
Taking a migration effort as a given, Gartner [Driver] recommends categorising applications along the following dimensions to prioritise your migration efforts:
- Business Process Change
- How often are new features introduced?
- Is the application dynamically changing to evolving business requirements on a regular basis?
- Code Quality
- Does the application have a low critical defect count?
- Does the code necessitate frequent patches and redesign of core components?
- Business Value
- Is the application mission critical and core to day to day operations?
- Does downtime equate to loss of revenue?
- Application Longevity
- Is the application at beginning or end of life cycle? Are you planning to replace it before 2012?
Once categorised, rank your application migration efforts as follow [Driver]:
- High business process change + long-term life cycle = highest-priority migration
- Low features changes + long-term life cycle = medium-level priority migration
- High feature changes + short life cycle = low-priority migration
- Low feature changes + short life cycle = lowest-priority migration
Migration Best Practices
Microsoft [MSPP] and Forrester [Hammond] both advise breaking up the migration into two separate phases:
-
Functional Equivalence - Focus on achieving the exact functionality of the VB 6.0 application in VB.NET. This guarantees that your application logic does not change because of the upgrade and provides a solid base from which to move onto the second phase of the migration effort.
-
Application Advancement - Exploit the .NET technology to add or improve functional areas of your application that would benefit from the many improvements available in the .NET Framework.
Microsoft [MSPP] and Forrester [Hammond] site scope creep, add-on testing costs and the lack of a solid base for further application advancement as some of the reasons why these two activities should not be lumped together.
Migration Phases
Source: [p27, MSPP]
Microsoft [MSPP] further recommends breaking up the upgrade process into separate phases that represent milestones in your upgrade project. They state that:
Some of these phases, such as planning, must be completed for the entire project before any other phases can start. Other phases can be applied to individual pieces of the application at the same time while other sections of the application are already in later phases. For example, if you have chosen a staged upgrade strategy, it is possible that some of the sections of your Visual Basic application are being prepared for upgrade while others have already been upgraded and are ready for testing.
The phases include doing the following:
-
Planning - Define goals, expectations and constraints; evaluate risks and determine the order in which modules should be upgraded; evaluate the cost of upgrading the application.
-
Preparation - Prepare the application for upgrade by modifying certain implementation details to reduce the manual work required after the upgrade tool has been used; use tools like Code Advisor and the Visual Basic 6.0 Upgrade Assessment Tool to identify problem areas.
-
Upgrade - Use tooling (i.e. Visual Basic Upgrade Wizard) to upgrade as much of the code as possible; manually upgrade the remainder of the code.
-
Testing - Demonstrate functional equivalence; conduct testing throughout the whole process, i.e. even in early stages of the upgrade.
-
Deployment - Deploy to ensure that the testing phase is completed.
-
Advancement - Implement/improve the application using new .NET features.
Other Considerations
Microsoft presents the following additional considerations for helping you to manage the risks associated with the upgrade [p66, MSPP]:
- Try to perform the upgrade during a period when you can restrict the coding on the application to solving major bugs.
- Assemble a dedicated upgrade team of developers and testers who know the VB6 application and have experience with the .NET Framework.
- Understand and categorize the upgrade issues that require manual intervention.
- Share upgrade knowledge with the entire team as a single solution may apply to all occurrences found.
- Make functional equivalence your goal even though your application does not entirely follow the recommended practices for .NET. These can be addressed at a later stage.
- Split the testing phase into partial/unit testing and full/system testing.
- Test cases can assist greatly with quantifying the progress of the upgrade process and to maintain a high level of quality in the application.
Microsoft also warns against the following pitfalls [p77, MSPP]:
- Resist the temptation to redesign the application while preparing the code for the upgrade.
- Do not try to improve the code produced by the upgrade tool if its works just because their is a .NET alternative for it. Leave this for application advancement.
- Focus on getting functional equivalence. Only then start improving and optimising the application.
Migration Options
Besides the free Visual Basic Upgrade Wizard that ships as part of Visual Studio .NET, Microsoft has also released the Interop Forms Toolkit that allows you to host .NET forms and controls within a VB6 application. This allows you to upgrade your application in a phased approach, one form at a time.
If you don't have the appetite for migrating your application by yourself, the following vendors provide porting engines that attempt to automate most of the process of converting your VB6 code base into .NET.
Artinsoft
Artinsoft uses their Visual Basic Upgrade Companion (VBUC) to port VB6 applications into VB.NET/C#. The VBUC is the Enterprise Edition of the free Visual Basic Upgrade Wizard that Microsoft includes in Visual Studio.
Some thoughts on Artinsoft:
- Principal author of [MSPP] and they support a wide range of migration tools which indicate that they have core knowledge and experience in migrating between different languages.
- Have migrated significant code bases for many different customers.
VB Migration Partner
A promising new vendor that is entering the market is VB Migration Partner. Their software is currently in end-life-cycle beta testing and they are planning to release during March 2008. They claim that their software delivers up to 10-15x less compilation errors than the free Visual Basic Upgrade Wizard.
Some thoughts on VB Migration Partner:
- They seem successful at porting quite a range of different types of applications that make use of some of the more esoteric features of VB6.
- Their porting engine has been designed specifically only for understanding VB6 syntax.
- They are new in the market and therefore still needs to establish a proven track record.
Other Vendors
Other vendors not discussed in this article that also provide solutions to automate the migration process include:
- S7 Software Solutions
- Fujitsu Consulting
Additional Resources
For additional material on porting your Visual Basic 6.0 applications, visit the following links:
E-Books
- Patterns and Practices: Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005
- Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET
WWW
- Visual Basic 6.0 Resource Centre
- VB Fusion - Page containing a wealth of information on how to use VB6 together with VB.NET.
- Refactor your way to migration success - Article covering the top ten refactorings for migrating from VB6 to .NET.
- Overview of changes from VB6 to .NET - Article that discusses the important language changes from VB6/VBScript to VB.NET.
- Converting VB6 to .NET - Three part series of articles with a thorough discussion of what the Visual Basic Upgrade Wizard can do.
Conclusion
I hope you find the information presented in this article to be a helpful resource in guiding your own VB6 migration efforts. I highly recommend reading through [MSPP] as it contains a wealth of information that touches on all aspects of your migration efforts.
Now back to those 1.5 million lines of code that we need to port 