TOGAF based lifecycle management for a conversion project

Stages of a typical migration project

A system that is up and running now as per the enterprise expectation, will be migrated to new architecture/ platform in near future, there are certain factors responsible for the same, which are described in this article later.

Following diagram depicts a typical lifecycle involved for a conversion project.

Why do we need conversion?

Typical reasons for conversion projects are:

1.       End of Life (EoL) for the technologies involved in the project, e.g VB6, SQL 2000, SQL7   

a.       This happens on account of rapid technology (software & hardware) enhancements in the market while the project not keeping up with the phase

b.      The enterprise too comfortable and proud of their legacy system, such that they are reluctant to change.

c.       Cost in terms of $, time, effort etc involved for the change.

2.       Enterprise acquisition and takeovers  

a.       Result of this is some systems getting discarded, some getting enhanced to adapt to the new enterprise ecology.

3.       Change in business vision & mission

a.       Loss making systems are generally discarded while the other systems are made to absorb the additional load.

4.       No development standards followed during development.

a.       Resultant is a big junk of useless, repetitive, unmanageable lot of code.

Stages in lifecycle of a migration project

The figure above shows the different stages and their progressions.

1.       Baseline current architecture: Migration project starts with baselining the current architecture. Here we typically document the various business activities performed across various sub application within the legacy application under consideration. There might be various sub application to the parent application which were built for meeting various technical & business demands and plugged in to the main application as the applications live progresses.

2.       The target application architecture framework:  Define the target architecture for the application. This target architecture depends upon the organization’s strategy to adopt either

a.       Greenfield based

b.      COTS based products available in the application domain.

3.       Opportunity, solution & Gap analysis: this stage consists of identifying the Gap between the current baseline and the target architecture and likewise either scale up existing team or form a new team or get in a third party to implement the solution.

4.       Migration planning: Once the Gaps are identifies the solutions are defined and opportunities are plugged in, comes the migration planning stage where the organization readies itself to adopt to the new system or new systems of changes, there might be a change in business process induced due to the new system, there might be user training and required, as a result of this system changes, there might be induced change on other systems due to hard coupling, which also might have to be changed. There might be redundant systems existing in other department or work units, which can be completely replaced by this new system changes. The planning phase involves an Enterprise architect, who identifies these opportunities, plans for these activities, etc.

5.       Risk & Mitigation planning: in this stage, the management and the enterprise architect identifies the risk of this migration on the enterprise businesses, mitigates these risks, decides on the backup plans and roll back plans in case of a unforeseen failure.

6.       Finally the implementation stage, where the organization goes ahead with the system implementation. And involves in production planning activities.