Software migration products are complex technologies that need to strike the right balance between automation and quality of the generated code.
At one end of the migration product range there are compilers, which take source code and translate it 100% automatically to a different language; a language that it is not fit for “human consumption” and cannot be easily maintained.
On the other side, there is the full manual upgrade, in which an engineer optimizes code quality at a very high migration cost.
In the case of Visual Basic 6 migrations, customers have several choices depending on which optimization is required. This article shows the criteria that should be analyzed when considering the acquisition of a VB6 migration product.
The .NET code generated by the migration product should allow the resulting application to evolve and scale up without any limitations. The end result should be, as much as possible, native .NET code, in order to take advantage of the platform features. This way, a trained .NET programmer won't find any difficulty in understanding and maintaining the generated code.
The migration philosophy behind the Visual Basic Upgrade Companion (VBUC) is to produce native .NET code and take advantage of the all the technologies available in the .NET Framework. Here are some examples of features where the VBUC generates high quality, .NET code:
Unlike the VBUC, other tools in the market generate code that looks like the original VB6 source code with most of its keywords replaced by the constructions contained in a runtime support library.
The maintenance over the resulting code is complex, and it looks and feels more like VB6 than .NET. As a result, the migrated application also faces lots of maintainability challenges, like the presence of proprietary graphical controls that can’t be mixed with .NET intrinsic controls.
A simple way of building a highly automated migration product is to rely on an extensive runtime library to reduce the gap between Visual Basic 6.0 features and .NET features.
That is, at its core, re-implementing VB6 in .NET. However, this approach will release you from one legacy environment only to lock you in with a proprietary runtime supported by a smaller company.
The migration philosophy behind the Visual Basic Upgrade Companion is to produce native .NET code with no dependency on the legacy platform or any third-party runtime, so that customers can effectively take control of the evolutionary path of the migrated applications without any restrictions.
To ensure this, the VBUC employs complex transformations and heuristics in order to generate VB.NET or C# code with the direct support of the .NET framework. Only when the difference in functionality is too high due to functionality differences or code readability and maintenance issues, the VBUC may make use of a small set of helper classes that are distributed, along with their source code, with the migrated code, creating no dependency on Mobilize.Net.
Using a large runtime might be an option to speed up the migration process, and can lower the initial cost of the VB to .NET migration (though in the long term it will always be more expensive to maintain a hybrid application on .NET), but if you decide to go with this approach you need to make sure that:
A migration product must be extensible and customizable because you're going to need the flexibility of adding functionality:
The Visual Basic Upgrade Companion provides the following mechanisms to customize the generated code:
Migration Profiles:Code Comments as Customizable Mechanism and Re-migration Capability
Other migration tools in the market use an approach where the user has to insert commented lines (something similar to compiler directives) in the original Visual Basic 6.0 source code. These commented lines are used by the migration tool to identify where the resulting code needs to be changed in some manner.
Years ago, Mobilize.Net used this approach in earlier migration tools and identified the following issues:
This approach (inserting comment lines into the original source code) can be used in very small migration projects without creating any unnecessary overhead to the overall migration process, but when the migration larger scale, the amount of manual insertions of the source code comments will raise the cost of the migration project significantly.
Some transformations may require a lot of comment insertions in the original Visual Basic 6.0 source code.
For example, if you want to convert all the VB6 error handling mechanism (On Error ... Goto) to the .NET structured error handing (Try ... Catch) you need to insert a comment for each transformation.
On a large project, this means that you may have to insert thousands of comments, and a comment into the original Visual Basic 6.0 code requires a similar effort that a manual change in the migrated code. On the other hand, the VBUC applies this transformation simply by switching on the On Error Handling feature in the Migration Profile.
Another common use for inserting comment lines into the original source code is to provide a re-migration alternative.
This means that the development team of the application can continue making maintenance changes into the VB6 source code while the migration team is upgrading the application to .NET.
However, this strategy requires that the migration team use the same base code that the development team is working on.
This requirement is not always feasible in large companies, especially because of information security issues.
Another problem is that the migration team will be working with an unstable version of the source code, increasing the testing cost of the upgrade project. In order to provide re-migration capability and avoid these issues, the VBUC team uses a proven, well-structured continuous migration methodology.
The level of automation is important because this feature will have a direct impact on the cost of your migration project.
There are some migration tools out there with a very low level of automation, and others that perform better but will generate low quality code and require the use of a huge runtime.
The key is to aim for a high level of automation without sacrificing quality of the generated .NET native code.
To evaluate the level of automation and the quality of the code generated by the Visual Basic Upgrade Companion you can get a trial version and test it on your own code, and if you need some assistance during the evaluation don’t hesitate to contact us.
It is also important to check on the level of expertise, available support and credentials of the vendor.
Mobilize.Net has been in the software migration business for more than 15 years, and has a proven track record of dozens of satisfied customers worldwide, including lots of Fortune 100 companies, representing tens of millions of lines of code successfully migrated to .NET.
All this is reflected in the design of our products, where our R&D department frequently releases new versions incorporating the experience gathered from real world migration projects and the requirements requested by actual customers, rather than relying on theoretic research that commonly yields useless, “we-did-it-first” features.
And besides its powerful migration products,
Mobilize provides extensive documentation and a full range of comprehensive, expert consulting services and dedicated support that will ensure that your overall experience will be as smooth as possible.
Contact us today to learn how you can migrate your legacy apps to .NET, web, mobile and cloud for a fraction of the cost of rewriting them
.
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com