6.1. Migrate, Replace, Rewrite, or Reuse?

Once an organization has decided that a certain application no longer meets its business needs and that doing nothing is no longer an option, modernization comes into play.^[1] There are at least four ways to approach the modernization of a VB application that should be considered. The deciding factors are:

^[1] The following section is an excerpt from the "Designing an Application Migration Strategy for Visual Basic 6.0 to Visual Basic .NET" whitepaper authored by ArtinSoft, published on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/appmigrationstrat.asp.

• The quality of the application code

• 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 of application

Generated errors, number of workarounds, and level of support needed.

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 reconstruct 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 lifecycle

In the earlier stages of its lifecycle, an application will likely map closely to its 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 be fully trained in VB 2005. Additionally, other factors such as the existence of test cases must be considered.

The business value of the application is another important consideration and this will depend to a considerable degree on its uniqueness. 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 any one of which can be the right choice either for a complete application or for parts of an application. Figure 6-1 shows how the decision factors correlate with the modernization path.

Migrate

If the VB application meets current business needs and its quality is good, chances are 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 chapter, 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 (see "Upgrading VB 6 Applications," later in this chapter).

Figure 6-1. Modernization options chart

Reuse

There are two possibilities here, one in which the application is centered on a third-party package/DBMS already, and the other in which the business has developed its own application from scratch. If the VB 6 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 integrating 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.

6.1.1. 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 you should consider when choosing one of the alternatives.

6.1.1.1. Migrate

Below is the 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

Resources needed to maintain or amend applications on existing platform are difficult to find

6.1.1.2. Reuse

Below is the checklist for choosing to reuse:

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

6.1.1.3. Rewrite

Below is the 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

6.1.1.4. Replace

Below is the 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 preceding questions can apply to complete applications or to discrete parts of applications. Typically a large application will require use of more than one modernization alternative. 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 require enhancements to its functionality, and if you already have support staff trained in VB 6, then leaving the application in VB 6 is a good option. Nevertheless, your organization needs to assess the risks of this approach in light of current lifecycle guidelines from Microsoft and the opportunities that the VB 2005 and .NET framework offer to your organization.

If there is a business need to move the application to VB 2005, then there is a need to look more closely at rewriting versus upgrading. Upgrading the application using the VB 6 to VB 2005 migration tool is a cost-effective way to migrate your applications. One popular reason for moving an application to VB 2005 is to either web-enable the application, or to 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.

There are some benefits to rewriting. Rewriting allows you to correct a 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 the upgrade has taken place.

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 VB 6, 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 is the case for most modernization projects.