Time to Mobilize
- Application Migration
- Database Migration
Even with the help of VB to .NET migration tools, it is critical to plan carefully in order to ensure success. This whitepaper presents eight recommendations that you should take into account when planning a code migration.
Companies still using Visual Basic 6.0 for application development are faced with the challenge of moving away from a platform that, as of March, 2008, is no longer supported by Microsoft (1). One option that is available to those companies is to use automated migration technologies to help migrate these application to Microsoft’s .NET Framework. Migrating from VB to .NET allows companies to leverage the investment in the current application, while moving into a fully-supported and updated development environment.
There are several tools in the market that can help with the VB to .NET migration process. Most companies offer a black box approach with a runtime that requires a customer to pay an ongoing maintenance fee. Companies like Mobilize.Net offer the Visual Basic Upgrade Companion, WebMAP and other migration solutions with a proven record of successful migration projects.
Even with the help of these VB to .NET migration tools, it is still necessary to plan the migration project in order to ensure its success. Mobilize has been involved in automated software migrations for more than 15 years, and has been working alongside Microsoft for more than 20 years performing VB to .NET, web and Azure migrations.
In this whitepaper we present eight recommendations that you should take into account when planning a Visual Basic 6.0 migration. These VB to .NET migration tips are based on Mobilize.Net's experience performing thousands of Visual Basic 6.0 to .NET upgrade projects.
Mobilize.Net has developed a very mature project methodology that allows for a predictable, controlled migration process. This is achieved by dividing the application upgrade into two main phases: first, getting an application in the new platform that has 100% Functional Equivalence to the original Visual Basic 6.0 application, and second, performing incremental changes to leverage the new functionality available in the .NET Framework.
Figure 1 Mobilize.Net Migration Project Methodology
The VB to .NET migration tips presented in this whitepaper are framed in this upgrade process. For more information, you can access Mobilize.Net's website at www.mobilize.net.
A VB to .NET migration project requires a plan for some pre-migration work. In this first part of the project it is essential to perform certain activities to improve the quality of the code that will be generated during the automated migration. There are two types of pre-migration tasks that involve changes to the Visual Basic 6.0 code base: Code Cleanup and Code Preparation.
The Code Cleanup activity is an opportunity to perform maintenance tasks on the code that are usually put off during the regular development cycle. This includes removing code that is no longer used, removing redundant functions or methods, and some basic code and project restructuring.
For the Code Preparation activity the developers should modify the application’s code to improve the quality of the generated code. There are tools out there that can help you identify code in the application that will not convert cleanly. Some issues are easier to fix in Visual Basic 6.0 than in .NET, such as the Use of #if and Non-Zero based arrays, so you should take care of them regardless of the migration solution you are using.
Also, keep in mind the following rule of thumb: Using high quality code as input for the VBUC generates high quality .NET code as output.
VB to .NET migration projects, depending on the company’s needs, can be structured in several ways. The two most common ways of establishing this order is to use either a Top-Down or Bottom-Up Visual Basic 6.0 to .NET migration.
Top-Down VB to .NET migrations starting with the Visual Basic 6.0 projects (*.vbp) you want and then working your way down to the migration issues, are recommended if:
Even though this is a very generic statement, there are a couple of things that can be done in a Visual Basic 6.0 to .NET migration project in order to mitigate risks. First of all, it is recommended that you convert a small, representative module (using a Top-Down approach) before starting the whole VB to .NET migration. This is useful in diminishing threats associated with:
Also, something from Mobilize.Net's experience that has been key in performing successful upgrades, is to migrate to functional equivalence first, and then start making changes to leverage the functionality of the new platform. This will be further expanded in Tip #5: Migrate to Functional Equivalence, then Re-Architect.
Migration projects are more QA-intensive than other types of software development efforts. You should allocate AT LEAST 35% of the total effort of the project to testing activities, though the ideal is to assign around 50% of the time for these tasks.
As for planning the testing, you should use a set of test cases as an objective validation for the migration process. The quality assurance team should make sure that these test cases execute correctly in the Visual Basic 6.0 application before running them on the migrated version. This should be done in parallel by the testing team with the first development activities of the project. This point is covered with more detail in Tip #6: Identify a Test Harness to Validate Functional Equivalence.
Making the decision to migrate an application means that there is significant value in the business rules and the logic embedded in it. The business may depend on these very specialized rules, so it is imperative to leverage the current investment by moving them forward. This is something very important to keep in mind during the migration project.
It is always tempting, especially for developers, to use the migration as an opportunity to rewrite parts of the applications that could work in a better way. On paper this sounds like the ideal time to do this, but in reality it is something that should be avoided as much as possible. Mobilize.Net's experience shows that doing a straightforward port to reach functional equivalence is a measurable, easy way to control the process. Adding additional technical complexity to the project by rewriting a large part of the application adds uncertainty, and can cause the project to go out of control. There will always be an opportunity to do some improvements while performing the migration, but if a decision is made to work on them, make sure that all stakeholders understand the impact that these changes may have on the overall migration effort.
VB to .NET migration projects should have measurable, deterministic criteria to establish when the project is completed. This will set realistic expectations with stakeholders in the project, and in turn will translate into a more manageable and controllable project.
In Mobilize's experience, using test cases is an ideal medium to validate when the migration is complete. Having a set of test cases will help the project to have very clear goals: to have the migrated application run the same test cases as the original system, and produce the exact same results.
If there is the possibility of using a third party to provide additional resources during the Visual Basic 6.0 to .NET migration effort, then special care should be taken to make sure that the test cases are as detailed as possible, without skipping any functionality of the application. Keep in mind that these additional resources are not experts in the application or its domain, so having detailed instructions will allow them to be productive very quickly, without having to undertake application-specific or domain-specific training.
Several VB to .NET migration solutions out there will release you from one legacy environment only to lock you in with a proprietary runtime. Over time, this approach leads to additional costs, namely:
Using a runtime might be an option when there is a significant difference with the target platform. This may speed up the process, and can significantly lower the cost of the VB to .NET migration, but if you decide to go with a runtime make sure that it:
This last bullet is especially important, not from a technical but from a business perspective. Being tied down with redistribution royalties may end up affecting potential business models you may want to explore in the future.
The team that is required to achieve a successful VB to .NET migration has a mix of skills and roles. The skills for positions such as quality assurance or project management are very similar to the ones required for any other software development effort.
At a high level, the profile of the developers that will be working in the code itself has three main skill sets, in decreasing order of importance:
Using automated migration tools as part of an overall upgrade project methodology is a good way to leverage the current investment in Visual Basic 6.0 applications and move them to the latest technology. Due to the VB to .NET migration tools that are available in the market today, like Mobilize.Net's Visual Basic Upgrade Companion, this has become a very viable proposition, especially given the fact that Visual Basic 6.0 is not supported by Microsoft.
A Migration Project presents some challenges that are not common in other types of software development efforts. With more than twenty years executing successful Visual Basic 6.0 to .NET conversion projects, Mobilize.Net has developed a proven software migration methodology, and the tips presented in this document are based on the experience accumulated over these years, having proved their value over and over again.
1 Product Family Life-Cycle Guidelines for Visual Basic 6.0 http://msdn.microsoft.com/en-us/vbasic/ms788708.aspx