MIGRATION OPTIONS

If you are thinking of embarking on a major migration of application systems to a new environment you will need to consider each system component separately. Key areas of the business, particularly those that no longer meet the business requirements, may benefit by being redeveloped or replaced by a package in the new environment, while the migration of other areas may be achieved best through conversion.

Systems may be migrated in three major ways.

• Through Development

The development option is where systems are migrated by means of a rewrite or by enhancing the system. This is usually prompted by a major shift in the business requirements.

In these cases, since business analysis and system specification will be performed before the extent of the development effort can be assessed; the costs and durations of these migrations are usually difficult to estimate. This, together with the potential for the misspecification of requirements, increases the risk of this option.

In addition, a large portion of any redevelopment effort is usually spent duplicating current functionality. As a consequence when considering redevelopment of systems, some consideration should be given to converting some of the migration workload in order to maximise the preservation of the existing investment.

• Through Package implementations

In order to define the package acceptance criteria, as with the development option, upfront analysis and specification is required. As with the development option, costs, durations and risks associated with these migrations are difficult to estimate.

Since packages rarely meet the exact business requirements, functional modifications are usually required.

In addition to the testing required to ensure a functional fit, the effort required to dovetail the package into current production environment and in converting existing data to conform to the package may be considerable.

• Through Conversion

Where the original system code may be used as the specification for the migration of an application to a new environment, the system may be converted without affecting the user's view of the system.

A special case of conversion is where the fundamental technological basis of the system may be altered. For example, in changing the underlying database structure or the programming language used by the system, reverse engineering and re-engineering techniques may be required.
 
Because the existing system's program code is well-defined and no business analysis or specification is required, the costs and duration of the conversion are usually significantly shorter than the equivalent development effort.

In addition, since the existing system's program code is not subject to change for the duration of the conversion, the costs and duration of the conversion may be accurately established, thus significantly reducing the risks of escalating costs and slipping deadlines usually associated with IT projects.