This chapter is from the book
This chapter is from the book
This chapter is from the book
Phases Involved in Migration
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
- Existing system type
- Migration goals
- Required deliverables
- Staff experience
- Size of the project
- Complexity of the project
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 I—Assessment
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 II—Reverse 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
Adding new requirements to recovered functional specification
Remove obsolete functions
Phase III—Forward 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:
Prototype design
GUI design
Database design
Module-level design
Program design
Unit test cases design
Integration test cases design
System test cases design
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:
Coding
Other QA activities such as code walk-through
Test the new system, including
Unit and module testing
Integration testing
System and acceptance testing
Phase IV—Installation 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