Iv&#225n; Sanabria
Alexander G
&#243mez; Alvaro Rivera
Carlos Maroto
H&#233ndel; Valverde
Federico Zoufaly

ArtinSoft

Updated December 2005

Summary: This article explores the complete process of a Visual Basic 6.0 to Visual Basic 2005 migration project. It covers all the aspects of migration, from the analysis of the business and technical requirements, to the guidelines for selecting a migration approach that include proven strategies and best practices. You will learn how to minimize the time and effort required for your migration through the application of proven strategies. (22 printed pages)

Applies to:
   Microsoft Visual Basic 6.0
   Microsoft Visual Basic 2005
   Microsoft Visual Studio .NET 2003
   Microsoft Visual Studio 2005
   Microsoft .NET Framework 1.1
   Microsoft .NET Framework 2.0

Contents

Introduction
Migrate, Replace, Rewrite, or Re-Use?
Making the Right Decision
Implementing an Automatically Assisted Migration Project
Conclusion
References

Introduction

There are many misconceptions on the right way to approach the upgrade of a Visual Basic 6.0 application to Visual Basic 2005, and on how much effort is required for such a migration. This document is intended as a guide to prepare a migration strategy. It describes a number of factors throughout the distinct stages of a migration project that should be considered to guarantee the successful completion of the project, as well as the best practices derived from the execution of multiple migration projects.

There are common drivers for considering the modernization of Visual Basic applications. These drivers can be viewed as a spectrum, going from push factors where the Visual Basic 6.0 application must react to fit a new set of business needs, to pull factors where the business wants to seize an opportunity to grow/reach new customers/add products and services leveraging the current application. These factors include increasing operation and efficiency resulting from maintenance costs and overheads of older applications while at the same time maximizing the benefits derived from using .NET.

Migrate, Replace, Rewrite, or Re-Use?

Once the organization has decided that a certain application no longer meets the business needs and doing nothing is no longer an option, modernization comes into play. There are some alternatives to the modernization of a Visual Basic application that should be reviewed. The deciding factors are (i) the code quality of the application, and (ii) the business value of the application. Quality in this case is about the suitability of the application in business and technical terms and should be assessed in accordance with the following parameters:

• Current effectiveness: that is, generated errors, number of workarounds, level of support needed, and so on.
• Stability and completeness of core business rules: will the application logic remain the same in the foreseeable future? An underlying assumption in this paper is that the current software asset is a valuable one. If the business model is going to change substantially then this assumption has to be called into question. In practice, the code is often the only repository of business rules and these are scattered throughout the code. Thus any attempt to 'start from scratch' needs to re-construct and document the requirements captured in the current code and take these requirements as the starting point for the negotiation of new requirements.
• Stage of the life-cycle: in the earlier stages of the life-cycle, an application will likely map closely to functionality requirements, although the platform could be obsolete.
• Development environment: the development team and the environmental capabilities required to successfully deliver a modernization project need to be assessed. Here, the developer's knowledge regarding the application source code, the target technologies, and the resolution of modernization issues identified during the code assessment are crucial. In general, it is recommended that developers executing the project are fully trained in Visual Basic 2005. Additionally, other factors such as the existence of test cases must also be considered.

The business value is another important consideration and this will depend on the uniqueness of the current application. If the quality of the application is poor and there is comparable functionality available in a third-party software package, it makes sense to replace it.

There are four broad modernization options—migrate, re-use, rewrite, or replace—which can be the right choice for a complete application or for parts of applications. Figure 1 shows how the decision factors correlate with the modernization path.

Figure 1. Modernization options chart

• Migrate: If the Visual Basic application meets current business needs and the quality is good, then chances are that the application can be effectively modernized to continue to meet the needs of the business in the future. In such cases, a migration process can be applied and then functionality and business reach can be added as needed. In this article, when we refer to a migration or an upgrade, we are referring to an automatically assisted migration using the Microsoft Visual Basic Upgrade Wizard that is integrated in Visual Studio .NET.
• Re-use: There are two possibilities here, one where the application is centered on a third-party package/DBMS already, and the other where the business has developed its own application from scratch. If the Visual Basic 6.0 application portfolio is largely centered on a third-party package, then the best way to move forward may be to upgrade to the latest version and use wrapping techniques to provide the required reach and other functionality improvements. For in-house applications consider wrapping the application pieces and integrate them with new development.
• Rewrite: The key asset here is the business rules and data structures—the application is the problem. Application mining and analysis of code logic and data structures is required to provide the starting point for the rewrite.
• Replace: Look for a suitable package or outsource. Be prepared to make changes to the business model to meet the package half-way.

Making the Right Decision

Upon the initiation of the project you should prepare a feasibility analysis that provides an assessment of the business and technical quality of the application. The following series of checklists presents some of the questions that may be considered when choosing one of the alternatives.

Checklist for choosing to migrate

• Existing application fulfills current business needs.
• Moderate functionality changes needed in existing application.
• High operational costs of existing application.
• Need to migrate to the .NET Framework for strategic reasons.
• Future vision includes the use of Web services or Web access.
• Stable code base and a test suite that certifies it.
• Difficult to find resources to maintain amend applications on existing platform.

Checklist for choosing to re-use

• Business rules satisfactory.
• Low operational costs of existing application.
• Simple Web access required, allowing a wrapping solution.
• Have resources to keep core Visual Basic 6.0 application maintained.
• Off-the-shelf software central to existing, rely on a third party to support and maintain.

Checklist for choosing to rewrite

• Functionality does not meet business needs.
• No off-the-shelf solution comes close to meeting needs.
• Poor quality code in existing platform and high maintenance costs.
• Can afford time, cost, and disruption involved.
• Need to use the Microsoft .NET Framework for strategic reasons.
• Future vision includes the use of Web services.

Checklist for choosing to replace

• Application significantly out of line with business needs.
• Willing to make changes to business model to fit off-the-shelf solution or availability of off-the-shelf solution that closely fit your business requirements.
• Can afford time, cost, and disruption involved.

The above questions can apply to complete applications or to discrete parts of applications. Typically a large application will require a balance of the different modernization alternatives. When deciding the best path for a particular part of an application, bear in mind that many developers will invariably say that rewriting your application is the best solution if you need to upgrade it because they usually feel they can write it better the second time, armed with the benefit of hindsight. Certainly if the application is poorly designed, rewriting it can be a good option because it provides an opportunity to do it right. However, examining the business case for upgrading, rewriting, replacing or leaving the application in Visual Basic 6.0 always provides some interesting insights.

If the application already supports your business needs, doesn't need enhancements, and you already have support staff trained in Visual Basic 6.0, then leaving the application in Visual Basic 6.0 is a good option. Nevertheless, your organization needs to assess the risks of this option in the context of the Microsoft Product Family Life-Cycle Guidelines and the opportunities that the Visual Basic 2005 and .NET Framework offer to your organization.

If there is a business need to move the application to Visual Basic 2005, then there is a need to look closer at rewriting vs. upgrading. Upgrading the application using the Visual Basic 6.0 to Visual Basic 2005 migration tool is a cost-effective way to migrate your applications. One popular reason for moving an application to Visual Basic 2005 is to either Web-enable the application, or enhance an existing Web-enabled application with ASP.NET features such as tracing, flexible state management, scaleable data access, and improved performance. As mentioned previously, rewriting sometimes yields an improved application. The downside is that the development cost will be much greater than upgrading. According to Artinsoft's consulting practice and the Software Research Institute (http://www.spr.com), an experienced Visual Basic programmer writes between 500 and 1000 lines of deployable Visual Basic 2005 code per month. The same programmer upgrading an application will process between 3500 and 4000 lines per month. Upgrading is three to seven times faster! The main reason for this huge difference is that a rewrite involves writing, testing, and debugging a new algorithm, whereas an upgrade means simply ensuring code runs as it used to.

There are some benefits to rewriting. Rewriting allows you to correct a previous poor design, and COM objects can be replaced with .NET objects that are more scaleable and don't require registration during deployment. The flipside of this is that upgrading is much quicker and COM objects can be replaced with .NET objects after upgrading.

In brief, you have to decide on how to move forward with your modernization project. If you decide that the best solution is to leave the application in Visual Basic 6.0, then you are done! On the other hand, if you have assessed that the best solution is to rewrite your application, then the best piece of advice is to make sure that you follow an accepted development methodology and that you really look back at the issue your current application has to make sure you can leverage that knowledge when moving forward. If you think your current application and its source code have value, and that by moving it to .NET you can extend its lifecycle, then you have decided that automatically assisted migration is the best solution for your code. Finally, you may decide to go for a combination of the above solutions, as it is the case for most modernization projects.

Implementing an Automatically Assisted Migration Project

In the remainder of this article we describe the implementation of a migration project in the context where you have decided to upgrade your application using the Microsoft Visual Basic Upgrade Wizard and the recommended methodology. As in a traditional development project, a software migration project requires an initial planning and design phase. In this section, we describe a way a Visual Basic 6.0 application may be analyzed, prepared, and migrated, and propose tentative steps to help you plan a migration project including aspects such as scoping, costing, and executing a migration project.

Functional Equivalence

There is an important principle used in automatically assisted migration projects known as functional equivalence, which is highly recommended when doing this kind of project. In the context of Visual Basic migration, this means migrating your Visual Basic 6.0 application to a Visual Basic 2005 application with identical functionality before adding new features. This guarantees that your application logic doesn't change and business rules are functional in the new application.

Functional equivalence is typically considered as an intermediate step of a complete migration project. Usually, there is little business value in getting to functional equivalence, so any migration plan needs to include actions and features you intend to utilize once you have finished with this intermediate step. Creating a system that is 100% functionally identical to the original system is sometimes considered as a counterintuitive milestone. This controlled approach offers several benefits that organizations rarely recognize until they are well under way into the project of rewriting the application.

• It contains a perfect specification of the system. A discrepancy in behavior or in output is easily demonstrated and gives the organization a clear way to measure the success of the migration project.
• It is the only way to avoid the difficult, expensive, and time-consuming process of making specifications for the existing application functionality. It prevents the danger of scope creep, and it facilitates the testing phases of the project. Nevertheless, you will still need to make specifications for the new functionality before starting down this road.
• It gives the organization a clear, easy-to-understand means of tracking the progress of the project.
• It relieves the strain on users to adapt to the new system and limits the entire change management process to the IT department.
• It is the fastest way for an organization to transition from old technology to new, and it is the fastest way for the organization to regain autonomous control and resume normal incremental maintenance activities for the system.

Understanding the Visual Basic Migration Process

Before starting your first migration project it is important to familiarize yourself with details about the migration process in order to define its scope. To achieve this, you may choose to migrate simple applications first until you and your team feel comfortable analyzing and solving generic issues in the migrated code. Avoiding projects with areas that don't have automatically supported upgrade paths (see the Application Analysis section) or that are tightly integrated with other technologies is a good practice for beginners. Once you are more experienced, you will be able to identify issues that can affect the execution of the project.

When migrating, review the Upgrade Report that the upgrade tool produces. The upgrade report contains information about the upgrade process, as well as a list of issues uncovered during the upgrade that will need to be addressed before your project can be run. Understand the different issue categories and the recommended solutions.

You can reduce the amount of issues to be addressed when preparing your Visual Basic 6.0 code previously. Section Preparing Your Code for Migration elaborates on this topic.

Learning to upgrade is like learning anything else; starting simple means you are learning in manageable pieces. Also, choosing a simple project means you'll have it up and running more quick, thus ensuring a feeling of progress.

When you are ready to upgrade a larger real-world application, choose one that will benefit from the new features of .NET so that you can review the process to functional equivalence and then to application improvement. Understand the way the architecture is going to be modified. For large applications, the principle of divide and conquer applies. A recommended approach is to upgrade it module-by-module. For instance, you may start with the client modules, and then move up the dependency hierarchy, upgrading the business logic and data tier modules. We elaborate on possible migration strategies later. Equally important is to ensure testing takes place as you go along; test each module of the application as it is upgraded so you know that you are on solid ground before moving forward.

Once all the above is done, you will be ready to scope your migration project.

Application Analysis

The purpose of the application analysis is to generate information that will be used to estimate the effort of the migration project as well as to create a technical profile of the application. The output of application analysis should cover the following items:

• Current and target architecture
• Inventory to migrate
• Source code metrics
• Handling of unsupported features
• Assessment of Upgrade Report information

Current and target architecture

Understand the current architecture of the application and the way its components will be replaced in the target architecture. For instance, you may plan to replace ADO by ADO.NET and ActiveX components with native .NET components. The resulting target architecture should also include those new blocks that will support the new application requirements. These new blocks result as part of the new requirements analysis and design.

It is likely that your migrated application will interact with other existing Visual Basic applications, modules, or components, and any application portion that you may decide will be reused, but not migrated. Identify those interactions within the application architecture and ensure that it is clearly understood what components and where may need to interoperate. Identify also those components for which .NET equivalents are available and will be used instead.

Inventory to migrate

Identify relevant source code that will be upgraded. This should include libraries, resources, and components. A dependency diagram in the form of a tree view of the application call graph can help you recognize all necessary Visual Basic 6.0 projects and files. Decide the way you want to proceed regarding dead code, you may either make it part of the inventory or exclude it partially or entirely. Tools like the ones mentioned in the following section can help you obtaining dependencies from your source code and by identifying dead code.

In addition, identify those application portions that will be migrated and those that will simply be reused, if any, including all components that the application currently uses. In the case of third-party components, determine the availability of native .NET equivalents.

Source code metrics

Obtain metrics information from the application source code. This information should include size metrics, like the number of lines of code, projects, forms, designers, modules, classes, components, user controls, and data sources; and usage metrics, like functions used, types, components, and variables, including where they are used.

Obtain the frequency of use of each component in the application. This information together with the way in which a component is used helps identifying how difficult it would be to replace it with an equivalent native .NET component after migrating the application.

The following screenshot shows sample metrics of the VCR source code. It gives partial information about data types and controls occurrences, the source code inventory (in the form of a tree view), and the location of specific uses of data types, in this case the Integer and String types.

Figure 2. Sample screenshot of the partial source metrics of the VCR sample

There are tools available that analyze your Visual Basic 6.0 code and generate reports with the information mentioned above. Examples of these tools are Project Analyzer from Aivosto and VB Compress Pro from WhippleWare.

Handling of unsupported features

Identify all those Visual Basic 6.0 features and how often they are used in the application that are unsupported in .NET. Investigate and prototype implementation alternatives in .NET that may fit your requirements and identify any additional supporting functionality.

The following is a non-exhaustive list of unsupported features in .NET, with tentative solutions when available.

• Dynamic Data Exchange (DDE): DDE methods are no longer supported. Applications that depend on DDE should either be revised to another method of inter-application communication or should be left in Visual Basic 6.0.
• DAO or RDO Data Binding: Data binding to a DAO or RDO data source isn't supported in Visual Basic 2005; the Data control and the RemoteData control have no equivalent. DAO and RDO can only be accessed using code. Applications that rely on DAO or RDO data binding should either be updated to use ADO or should be left in Visual Basic 6.0.
• Visual Basic 5 Controls: Visual Basic 6.0 included the Visual Basic 5.0 versions of the Windows Common controls and the Data-Bound Grid control. These controls are incompatible with Visual Basic 2005. Applications that rely on these controls should either be updated to use the 6.0 versions or should be left in Visual Basic 5.0.
• DHTML Applications: There is no equivalent in Visual Basic 2005. However, DHTML applications can interoperate with Visual Basic 2005 technologies.
• ActiveX Documents: There is no equivalent in Visual Basic 2005. However, ActiveX applications can interoperate with Visual Basic 2005 technologies. ActiveX documents should either be rewritten as User Controls, or left in Visual Basic 6.0.
• Property Pages: There is no equivalent in Visual Basic 2005. If your application depends heavily on property pages, it should be left in Visual Basic 6.0.
• Web Classes: These are partially supported in .NET. Additionally, Web Classes can interoperate with Visual Basic 2005 Web technologies. Web Class projects can also be upgraded to ASP.NET Internet projects, with the possibility of making use of many of the additional ASP.NET functionality.
• OLE Container Control: There is no equivalent in Visual Basic 2005. The Browser control can be used to simulate this functionality in applications that use this feature.
• Single-tier Database Applications: Because data binding to DAO isn't supported, simple applications using controls bound directly to a local database (such as one created with Microsoft Access) may require a significant amount of rework.
• Visual Basic Add-ins: Because Visual Basic 2005 uses the Visual Studio integrated development environment the object model for extensibility is significantly different than that of Visual Basic 6.0. Add-ins will require a considerable amount of rework.
• Games: Applications relying on specific performance characteristics of Visual Basic 6.0, such as arcade games, will require rework because Visual Basic 2005 has different performance characteristics.
• Graphics: There is no support for the automatic upgrade of graphics methods of forms or for the shape and line controls. Applications that use these features extensively to draw on forms will require considerable rework.
• Drag-and-Drop Functionality: The models for drag-and-drop functionality are significantly different. Any code performing drag and drop actions will need to be rewritten.
• Windows APIs: Windows APIs are migrated. However, due to language changes, you may replace many calls to Windows APIs with .NET Framework functions.
• Printer: There is no support for this object. Applications that use these features extensively to print from the code will require considerable rework. Similar functionality is found in the System.Drawing.Printing.
• Printers Collection: This collection is no longer supported in Visual Studio 2005. In Visual Basic 6.0, the Printers collection was used to direct the output of a Printer object to a different printer. The Printers collection contained a list of available printers that matched the list displayed in the Windows Print dialog box. In Visual Basic 2005, the Printers collection is replaced by the PrintDilog control, which provides a standard Windows Print dialog box.
• Forms Collection: This collection is partially supported in Visual Studio 2005. Applications that use this collection will need to be partially rewritten.
• ClipBoard Object: This object has a different behavior in Visual Studio 2005. Applications that use this object will need to adapt the functionality of this object to the DataObject, which has a similar functionality.
• Functions: Some functions like Lset (in special structure cases), MidB, LenB, AscB, Dir, LoadResStrings, unload, String, CVErr, IMEStatus, VarPtr, ObjPtr, and StrPtr are no longer supported in .NET, and applications that use these features will require considerable rework.
• GoSub: In Visual Basic 2005, the Gosub...Return and On...Gosub statements are no longer supported. These statements were supported in Visual Basic 6.0 for compatibility with earlier versions of the Basic language; they are not compatible with object-oriented programming practices.
• Late-bound default property reference could not be resolved: In Visual Basic 6.0, objects had a default property that could be used as a shortcut in code. However, late-bound objects cannot be resolved because it is impossible to determine a default property without knowing what the object is.
• TypeOf: In Visual Basic 6.0, the TypeOf function was used in If...Then...Else statements to determine whether an object reference was of a specified object type. In this context, a user-defined type was considered to be an object type.
  ln Visual Basic 2005, user-defined types (now known as structures) are not object types and cannot be evaluated by the TypeOf function.
• Event parameter was not upgraded: Some event parameters that were supported in Visual Basic 6.0 are no longer supported in Visual Basic 2005.
• PopupMenu: This function is no longer supported in Visual Studio .NET. There are different types of menus in the new Visual Studio .NET Structure, where for example the context menu is an object apart of the MainMenu. Due to this new structure in all the related with menus applications with PopupMenu function will require rework.
• ClipControls: These controls are no longer supported, functions like Line and Circle are not available in Visual Studio .NET. The same functionality is found in System.Drawing namespace, but applications that use these functions will need to rewrite the code.
• License Collection: A collection of LicenseInfo objects that contain license key information required when adding a licensed control to the Controls collection. This will require a considerable amount of rework.
• Constants in an Enum: Visual Basic 6.0 enum members are commonly promoted to Integer values. In .NET these enum members may not necessarily correspond to the same integer values of those in Visual Basic 6.0.
• Mouse Pointers: Setting a MousePointer to a vbCustom icon in Windows Forms like in Visual Basic 6.0 is no longer supported in this same fashion in .NET.

Assessment of upgrade report information

The Upgrade Report provides you with all of the upgrade issues encountered and how many times they occur in the application. Each issue type is identified by an issue number, a description and a link to related documentation including possible next steps. For instance, the issue number 1037 corresponds to Late-bound default property reference could not be resolved. Issues occur due to the following main reasons:

1. Unsupported features (refer to section Handling of Unsupported Features).
2. A small fraction of Visual Basic 6.0 core functions for which there is no equivalent in .NET or core functions that showcase a new behavior.
3. ActiveX controls that are migrated to .NET controls, where some members of these ActiveX controls are not supported by the .NET ones. For instance, some properties and method of standard Visual Basic 6.0 components have issues associated with them when upgrading to .NET components.
4. Language changes in which the Visual Basic Upgrade Wizard actively warns you and requests you to manually review, like in the case of default properties in Visual Basic 6.0.

The following figures from ArtinSoft's consulting practices show that the top ten most frequently occurring issues account for 94.5% of the total upgrade issues. This figure was obtained form the migration of Visual Basic 6.0 projects, which corresponds to 1,470,000 lines of code, where the Visual Basic Upgrade Wizard issued a total of 16,507 issues. That is, there is an issue for every 90 lines of source code. This figure can increase to 120 lines of code per issue when preparing the source code for migration.

Obviously, the composition of the top ten issues in your application may vary depending on its architecture.

To analyze upgrade issues in your application, it is essential to understand that they can be categorized into two main groups:

• Not upgraded or unsupported issues: These issues signal the presence of unsupported features (refer to section Handling of Unsupported Features), uses of control properties or methods, or statements that require manual intervention. All issues in this group prevent successful compilation of the migrated application form.

  Artinsoft's consulting practice experience is that, once unsupported features are addressed, 95% of the remaining issues in this group are resolved by a simple code analysis to find a solution in .NET. For instance, some classes and methods of the COM+ interface, like ObjectContext and Commit are not upgraded. Equivalent members and functionality can be found in the .NET namespace EnterpriseServices. The remaining 5% requires either some minor change of the application logic or the implementation of small supporting functionality.

• Different behavior issues: These issues signal that the migrated code may have a new behavior that differs from the original one, and that you should manually review the possible consequences under the code context in case modifications might be needed. Issues in this group don't prevent the migrated application from compiling successfully but may produce runtime errors and make the migrated application fail. Artinsoft's consulting practice experience with this group of issues is that:
  • Only a few of them require manual intervention.
  • They provide guidance while unit testing the migrated application. For this reason, it is recommended not to remove them during a static review of the code but after successfully completing unit testing.

For each of these groups of issues, identify the different issue numbers and their frequency as shown in the table above. Analyze alternative solutions and the implementation effort for the most frequently occurring issues first. Then, follow through with all non-upgraded or unsupported issues as they represent an important source of work in any migration and the different behavior issues afterwards. A practical way of obtaining meaningful effort information is by running a pilot migration exercise where most issues, if not all, are resolved. New requirements can also be assessed in the pilot.

Scope Definition

The definition the migration scope in terms of the business and technical requirements obtained from the requirement analysis and design phases should be the output of the scope definition. While scoping your migration project, evaluate the need of prototyping (in the sense of Proof of Concepts) the resolution of the major migration issues you foresee, such as handling of unsupported features or re-architecture. This will help you avoid time wasted in poor coding decisions when migrating your applications, which allows you to validate any solution beforehand in isolated conditions and provides you with valuable data for estimating the migration cost.

Is your infrastructure ready for the change? Will the migrated application and its component be able to run on the existing platform? Define the way in which achieving functional equivalence will be measured. To measure functional equivalence, identify within your existing test suites and/or create a new set of test cases, also known as the equivalence criteria, and prepare testing mechanisms to validate it in the migrated application. In this way, the equivalence criteria become a useful mechanism to measure migration progress to verify when the functional equivalence has been reached and to avoid moving targets.

Preparing Your Code for Migration

Almost without exception, if you take steps to prepare your application in Visual Basic 6.0 before migrating it, the upgrade will be quicker. The following are the recommended steps in the code preparation phase:

1. Identify the entire source code inventory to be upgraded.
2. Determine the dependency between the Visual Basic 6.0 projects in this source code. This information is available for each project in the Project References and Components options of Visual Studio.
3. Make sure all dlls these projects require are properly installed in the machine that will be used for upgrading. The successful execution of the following step indicates that all dlls are installed.
4. Make sure all Visual Basic projects compile. Use the Make exe/dll command for this purpose.
5. Use the Visual Basic 6.0 Code Advisor to review and adjust your source code. The Visual Basic 6.0 Code Advisor is an add-in that can assist developers in making a successful transition to Visual Basic 2005. Once installed, the add-in can scan your Visual Basic 6.0 projects to ensure they meet predetermined coding standards. The Code Advisor can also suggest changes and best practices to ease your migration from Visual Basic 6.0 to Visual Basic 2005, and enables you to create custom scanning rules to check your Visual Basic 6.0 code for compliance with your own personal or development team best practices.
6. The Code Advisor Report provides you with details on architectural issues, like the present of controls in your Visual Basic 6.0 projects for which there is no equivalent in .NET to upgrade to; minor issues, like the need to declare a variable with an early-bound data type and its location within your code; the components used and the scanning rules results. Two examples of scanning rules are: the detection of non Zero lower bound arrays and the detection of On ... GoTo statements, both of which are not supported in Visual Basic 2005.
7. Use the Visual Basic Upgrade Wizard to run an initial migration of each Visual Basic project and review the resulting Upgrade Reports. Look for upgrade warnings 1037 and resolve them in the source code. The resolution work of this warning consists of declaring all variables as when using the "Strict On" directive and/or providing a type for all variables. Avoid the use of the Variant type.
8. Review additional preparation recommendations that may apply to your source code.

You may need to do a few iterations over these steps before deciding your code is fully prepared to be migrated.

The speed of the migration will be depends on the characteristics of the source code: for example, a single variable defined as a variant will generate an upgrade issue each time the variable is subsequently referenced. This can create a lot of issues. Artinsoft's consulting practice shows that for every upgrade issue resolved during preparation in Visual Basic 6.0, it saves the Visual Basic Upgrade Wizard from issuing between 5-8 issues. The following table corresponds to a sample of this practice.

Upgrading Applications Written in Earlier Versions of Visual Basic

The Visual Basic Upgrade Wizard is designed to upgrade Visual Basic 6.0 applications. For projects written in Visual Basic versions 1 through 5, it is necessary that you upgrade them first to Visual Basic 6.0 before upgrading to Visual Basic 2005. To upgrade a project to Visual Basic 6.0, simply open the project in Visual Basic 6.0, and save it. If Visual Basic 6.0 prompts you to upgrade controls to their Visual Basic 6.0 versions, choose Yes. If the project contains Visual Basic 5 ActiveX controls, it is often best to replace these controls with Visual Basic 6.0 versions. This is due to the fact that these controls use a different threading model than Visual Basic 6.0 controls, which is not supported in Windows Forms.

For projects written in Visual Basic versions (1,2,3 and 4 16 Bit), you may need to make extra modifications to the migrated project to get it working in Visual Basic 6.0 because some VBX controls will not be automatically upgraded. You will also have to replace Win16 Windows APIs with their Win32 counterparts.

Visual Basic versions 2 and 3 often require an extra step. Visual Basic 6.0 can only open files in Text format, whereas Visual Basic versions 2 and 3 support two file formats: Binary and Text. Before upgrading these projects, ensure the entire application is saved in Text format. To do this, select each file in the project and choose the File|Save As menu item. Check the Save As Text checkbox on the resulting Save dialog. Since Visual Basic 1 only saves in 'Binary' format, these projects will need to be opened in Visual Basic 2 or 3, and saved as text before they can be upgraded to Visual Basic 6. After following these steps, you can upgrade the newly created Visual Basic 6.0 project to Visual Basic 2005.

Migration Strategy Definition

Once you have decided to migrate part or all of an existing application, you then need to decide how best to approach the migration to .NET. A traditional module-by-module strategy is recommended in general terms, but this might not be necessarily feasible or practical in all cases, mainly due to the application architecture or size. In such cases, you may need to approach the migration process in one of the following ways:

• Vertical migration, which involves isolating and replacing a piece of your application through all n-tiers.
• Horizontal migration, which involves replacing a whole tier of your application.

To assure functional equivalence independent of the chosen strategy, it is necessary to put together comprehensive unit and system test suites for the whole system, as well as for individual migration modules, tiers or pieces.

We will now refer to the horizontal and vertical strategies for application migration in more detail to help you identify the suitable solution based on your application architecture. Application architects should be highly involved in this strategy selection.

Vertical migration

In the vertical migration strategy a portion or portions of the application that cut through several, if not all, application tiers are identified and selected for migration. This fundamentally involves carving out a piece of the application that has minimal interaction with other pieces and migrate it.

If parts of the application are well isolated from others, you have a good candidate for vertical migration. Such isolated parts typically share very little state information with the rest of the application and can be easily migrated with minimal impact on the rest of the system. If it is necessary to add new functionality to any of these parts to migrate it is strongly recommended that you use the .NET Framework to develop the new functionality.

The following scenarios represent two instances where it is best to choose the vertical migration strategy.

Heavy use of ADO recordsets between tiers

Many applications pass disconnected ADO recordsets from the data and business tiers to the presentation tier. The presentation tier then iterates through the recordsets and generates HTML tables. This type of application is well suited for a vertical migration. In this case, for instance, concentrating on the ADO to ADO.NET migration would minimize the work involved in achieving interoperability with ADO.

Planning to redesign

Migrating parts of your application to the new architecture using a vertical strategy provides a good test bed for the new design. .NET Framework readiness to provide new architectural support makes it much easier upon which to build your migration. For example, you can use HttpHandlers in .NET to perform many of the tasks for which you would have previously used ISAPI extensions, but with a much simpler programming model.

When following the vertical strategy, once the chosen portion of the application is migrated, any integration between the new managed code and the existing unmanaged code functions through interoperability. You will need to do some development and testing work to ensure that the new and old pieces of the site work together, share data, and provide a seamless experience to the end user or client developer. After this, you will have the basic infrastructure that will make it possible to continue with the migration of other applications in the system using the same vertical approach or to extend the migrated portion of the system.

Horizontal migration

In a horizontal migration strategy, you migrate an entire tier of your application to .NET without immediately migrating the other tiers. By migrating a single tier at a time, you can take advantage of the specific features that the .NET Framework provides for that particular tier, in many cases without modifying application code or affecting the operation of other application tiers.

Deciding which tier to migrate first is the initial step in a horizontal migration strategy.

Middle-tier COM components can be migrated to .NET with few or no changes to the presentation tier. You should consider the following points when deciding if a horizontal migration strategy is appropriate, and if so, which tier is the most appropriate to migrate first.

• Large number of Web servers: A pre-requisite for the deployment of a Visual Basic 2005 application is that the CLR has to be installed on each Web server. Having your application deployed on a large number of servers in a Web farm configuration can be an issue. Consider migrating the middle tier first in a horizontal migration if you have considerably fewer middle tier boxes.
• Shared code migration: If, as typically occurs with Visual Basic code, a large amount of shared code, constants or custom libraries are present in the middle tier then choosing to migrate this tier first can help you manage the migration of your whole application.
• Complex middle tier: Complex object hierarchies in the middle tier should be kept as a unit. Deciding where to isolate an application with a complex middle-tier object hierarchy is difficult, and migrating only parts of a complex middle tier typically necessitates numerous interoperability calls between environments, resulting in performance degradation.

You should consider also the following issues when replacing the middle tier:

• Transparently replacing middle tier components with .NET components without affecting client code, you will need to maintain the original GUIDS and/or ProgIds of your COM components.
• Properly handling replacement of the class interface generated by Visual Basic components when attempting to transparently replace a COM component.
• Translating the ADO.NET datasets returned from your migrated middle-tier components to ADO record sets used in your original Visual Basic code.
• Deploying the interoperability assemblies for the middle tier components.

Cost Estimation

Estimates of cost and time in software development projects are generally complex tasks, due to the wide range of quality in software implementations and the wide range of programming ability in software teams. Code migration is no exception. Many factors affect the amount of effort required to upgrade applications. These factors can introduce an order-of-magnitude difference in costs from one application to another and also from one organization to another. For this reason, we will present you with cost drivers that you will need to evaluate in the context of your application and infrastructure to estimate the migration cost.

The following are the cost drivers that we recommend taking into consideration when estimating the final cost for migration of applications:

• Resolution of unhandled features: For each of these features, estimate the research cost of alternative solutions, the development and testing cost of any support functionality the chosen solution may require, and the cost of replacing the unhandled feature multiplied by its frequency in the migrated application.
• Resolution of reported issues: For all issues in the Upgrade Report estimate the resolution cost. For this, it is recommended to carry out a pilot migration exercise of a representative portion of the application to obtain accurate information on the resolution cost of issues. This will also provide valuable insight about your team's capability to deliver the migrated application.
• Testing: For each Visual Basic project in the application, estimate the testing cost. The pilot migration exercise recommended above should also provide valuable information on this test. Evaluate whether your current testing suites need extension or adjustment to properly certify the functional equivalence first and then the new requirements then of the migrated application. Estimate the cost of such extension or adjustment.

  Also, understand and cost the testing coverage the migrated .NET application may require in contrast to the usual (possibly partial) testing performed on a Visual Basic 6.0 release. As a result, you may find that applying your full regression test suites to the migrated application can take longer and require several testing iterations, which might affect the usual testing cost.

• Replacing Visual Basic 6.0 components by .NET equivalent components: For each Visual Basic 6.0 component that is planned to be replaced by a .NET equivalent and that the Visual Basic Upgrade Wizard can't replace, then estimate the cost of replacing it manually times its frequency in the migrated application.
• Third-party .NET components: Obtain the license cost of all .NET components that you have planned to use in the migrated application from the corresponding providers.
• New requirements: Estimate the cost of designing, developing, and testing the new requirements in the migrated application using your organization experience in software development projects.
• Deployment: Estimate deployment cost of the migrated application. In general .NET presents a much more streamlined deployment mechanism than old COM based applications.

Furthermore, there may be other cost drivers within your organization that need to be part of the cost estimate. A sensible way to look at these other cost drivers is by using your organization experience in the pricing of other software development projects. Examples of typical cost drivers in organizations are: technical resource availability, and the readiness of the development and testing teams and the infrastructure available to adopt a new technology.

Using all this information, you can produce the estimated cost (man-hours) required for the migration project. Experience gained from Artinsoft's consulting practice shows what is one of the most notable differences between traditional and migration project structures: while testing in traditional projects represent a 20% to 30% of the total cost, testing in migration projects can easily represent 60% to 70%, where the absolute number of hours for the project is much smaller.

Migration Plan

When planning a Visual Basic migration, we recommend ensuring your project plan allocates time for the following activities in addition to all those tasks your organization typically includes when executing software development projects:

• Scope definition and revision
• Current and target architecture
• Analysis and design of new requirements
• Selection of migration strategy
• Inventory to migrate
• Source code preparation
• Source code metrics
• Handling of unsupported features
• Assessment of Upgrade Report information
• Per each project
  • Project migration using Visual Basic Upgrade Wizard
  • Stabilization (resolution of not upgraded/not supported issues) and (resolution of different behavior issues)
  • Unit testing
  • Clean up and release
• Functional equivalence validation
• Implementation of new requirements
• Acceptance testing
• Deployment

All these tasks have been previously discussed in this paper.

Executing the Migration

Based on Artinsoft's consulting practice, several pieces of information define the way the migration should be executed: the chosen migration strategy, the order in which the selected application projects will be migrated, the upgrade report information, and the dependency diagram of the application. It is highly recommended to begin migration with projects that have the fewest dependencies and only a few un-updated or unsupported issues (refer to section Assessment of Upgrade Report Information).

For each Visual Basic 6.0 project, the general migration process consists of the following tasks:

1. Upgrade the project using the Visual Basic Upgrade Wizard.
2. Stabilize the migrated project by:
   • Making it compile successfully. This implies resolving all not upgraded/not supported issues.
   • Reviewing the reported cases of different behavior issues.
3. Unit test the migrated project.
4. Clean up source code from upgrade notes and issues comments, and release the migrated project for new requirements to be implemented and for other projects that refer to it to be migrated using this same migration process.

Figure 3. Migration process for each project in an application

This process will be quicker when preparing your code prior to migration (see section Preparing Your Ccode for Migration).

Note that third-party ActiveX and COM components unknown to the Visual Basic Upgrade Wizard will not be automatically replaced by a .NET equivalent component but used through interoperability. No issues are typically produced here, but if you have planned to replace them by some equivalent .NET component, then manual work will be necessary to replace them.

Conclusion

Despite the challenges, modernization of applications is crucial for organizations spending too much time and money to maintain the business value of their outdated information systems. Also, driving the need for change is the industry's movement toward new Internet-based platforms, including .NET. This new computing paradigm leverage a component-based, distributed computing model capable of automating business processes internally or with partners using Web services. Adopting newer computing systems can cut operating costs and make it easier to adapt an IS to market changes or competitive pressure.

A variety of options exist, including replacing the system with a packaged application or non-intrusive measures, such as screen scraping and code wrapping. Each of the approaches makes sense under certain circumstances. The latter methods provide quick and inexpensive access to old functionality, while the former can eliminate outdated applications in which the code quality is too poor to migrate. But for those companies looking to preserve and extend the functionality of their Visual Basic 6.0 system to .NET, migration using today's automatic tools may be the most cost-effective approach.

In this article we described in detail how to approach a Visual Basic 6.0 migration project to Visual Basic 2005. We provided a checklist to help make a decision on how to approach the modernization of the application, and a number of best practices on how to minimize the impact of a migration project into your IT plan.

Every Visual Basic 6.0 system needs to be observed with the lenses provided by this paper. The final goal is to recover as much useful logic as possible from the current application while at the same time prepare for a modern architectural deployment. These goals are not antagonistic, they can both be reached in synchronization to minimize the cost and risk of a migration and assure the evolution of the .NET application in the years to come.

References

• Federico Zoufaly, Issues and Challenges Facing Legacy Systems
• Microsoft .NET/COM Migration and Interoperability
• Microsoft Visual Basic Developer Center
• Preparing a Visual Basic 6.0 Application for Upgrading
• Preparing Your Visual Basic 6.0 Applications for the Upgrade to Visual Basic 2005
• Upgrading to Microsoft .NET
• Visual Basic Concepts: Things to Consider Before Upgrading
• Visual Basic Concpets: Why Upgrading Is Necessary
• Ben Wilson, Tony Van der Beken. Observations on Automation in Cross-platform Migration, ELISA, 2003
• Declan Good: Legacy Transformation, Club Investigación Tecnológica, August 2002.
• Software Productivity Research. Programming Language Table, Fall 2003