| The methodology presented here supports the full spectrum of activities that constitute a migration project. It provides guidelines for various phases. Depending upon the project type, some of the activities and tasks can be executed simultaneously . Sequencing and timings of these tasks and activities should be defined during the planning stage of the migration project. Table 1-1. Phases of Migration | Phase | Activities | | Phase I: Assessment | Study and analyze existing system Establish design goals for the new system Do a cost-benefit/risk analysis | | Phase II: Reverse Engineering | Recover software design artifacts Define functional specification for the new system | | Phase III: Forward Engineering | Design the new system Apply migration changes to the existing application Construct the new system Test the new system | | Phase IV: Installation | Develop necessary operation manuals and procedures Install new hardware and software environment Execute production trial run | It is important to note that the migration methodology can be customized according to This methodology should not be viewed as a set of rigid procedures. Each phase, task, and activity need not be executed for all the projects. The process of customization requires selecting, deleting, adding, combining, and sequencing various phases, tasks, and activities. It is necessary to update migration methodology as a result of ongoing project experience. We will look at each of the features in the following sections. Phase IAssessment Assessment is the first phase of a migration project. It involves developing an understanding of the existing system. This can be carried out through various activities such as interviews, application demonstration, meeting with system experts, and evaluation of proposed (new) system architecture. This will help in deciding the migration path from an existing system to a new system based on the methodology provided in this document. It involves preparing a detailed migration plan. Assessment activities can be classified into three categories: -
Understanding the existing system and its development environment. This is achieved through -
Review of existing system documentation -
Interviews, meetings, and application demonstration with system experts (such as business leaders , developers and maintainers, users, etc.) -
Review of system history records (change log, error log, maintenance records) -
Analysis and decision making. Based on the analysis of the existing system, business goals and objectives, customer needs, and migration recommendations, the following decisions are made: -
Migration goals and objectives -
Scope and extent of migration efforts -
Migration strategies and technical approach -
Development environment and architecture of new system -
Critical success factors for the migration effort -
Planning. Once the decision to migrate the existing system is affirmed, the following plans for the migration efforts are prepared: -
Reverse-engineering plan -
Forward-engineering (development) plan -
Test plan -
Configuration management plan -
Data conversion plan -
Installation and cutover plan -
Training plan Phase IIReverse Engineering The purpose of reverse engineering is to recover and reconstruct software design artifacts such as DFDs, business and validation rules, and key data elements of the existing system. Types of the artifacts to be recovered and the effort involved depend upon the goals and objectives of a migration project and also upon the gap between existing system documentation (such as functional specification, design document, etc.) and the running system. The following steps will form a major part of this phase: -
Carry a program-level code walk-through and detailed analysis. The following factors would be evaluated during this phase: -
Module-level functional description -
Functional hierarchy -
Program control flow diagrams -
Data flow diagrams at each level -
Business rules -
Cross-references -
Entity relationship diagram -
Handling of locks in each module -
Error and help message handling -
Identifying common libraries and functions -
Identifying components and Active X controls -
Data source details -
Mapping between application domain entities and data source -
Help files and lookups -
Informal comments and observations. -
Based on information recovered from the program-level code walk-through, regenerate functional specification document and other higher level software artifacts of the current system. -
Create the functional specification for the new system by Phase IIIForward Engineering The aim of the forward engineering phase is to design, develop, and test the new system and migrate the existing system. The design artifacts of the existing system recovered in the reverse engineering phase and the functional specification of the new system form the major inputs to this phase. The selection of a software development life-cycle model (Waterfall, RAD, Prototype, etc.), which depends upon the type of the application, will affect the activities involved in this phase. Activities given below are quite generalized and should be tuned accordingly : -
Design the new system; it will include following activities: -
Migrate the existing application code to newer programming language. For Visual Basic this will involve migrating Visual Basic 6.0 code to Visual Basic .NET and will include following activities: -
Pre-migration changes in original source code as recommended in this book -
A run through of the upgrade wizard (for Visual Basic code) -
Post-migration changes as presented in this book For Visual C++ and ASP applications there is no concept of an upgrade wizard and hence there is no clear demarcation such as pre- and post-migration. -
Construct the new system. It will include following activities: -
Test the new system, including Phase IVInstallation and Release The installation and release phase identifies all the installation- related activities and procedures, and sequences and schedules these activities in an installation plan. The installation plan should be prepared much earlier in a migration project and installation progress should be reviewed periodically. Release involves putting the new system into operation. Before moving into operation, it is important to have a trial run and evaluate the results. If required, the trial run should be repeated until the desired results are achieved. The new system should become operational only after it is acceptable to all the users. This phase will involve following steps: -
Procure and install the new operating hardware and software -
Review results of UAT trial run and initiate corrective action -
Release new applications  |
