Planning Your Migration Project

With a successful project justification and approvals in place, you need to start building a vital infrastructure that will make the migration successful. This section details the tasks involved in planning a migration project. From a high level, building the infrastructure involves the following tasks :

• Defining scope

• Understanding risks and planning contingencies

• Organizing the project team

• Developing a project plan

While the earlier chapters of this book focused on the reasons behind migrations and general technical strategies to approach them, this section starts addressing the logistics involved with turning a migration plan into a reality. It takes you through a detailed implementation of the migration methodology, illustrating key points with a sample migration project plan. In addition, this section presents techniques for identifying and assembling the technical skills necessary to execute the project plan.

Defining Scope

As with any complex project, scope must be tightly defined and zealously controlled throughout the project. Scope creep is the number one threat to any migration project. Be prepared for people to try to seize upon the project to change some detail of the solution (be it hardware, software, tools, processes, or management) for their own needs. These attempts must be resisted at all costs. Migrations are complex projects when they have a proper scope, and additional challenges can mean the difference between success and failure.

In addition, however, you must ensure that scope is not too tightly defined. Shortcuts and omissions that occur during the architect phase will be uncovered during the implement phase, often resulting in a need to adjust the scope of a project. This flexibility to adjust scope, but only when absolutely required, can be the difference between the overall success or failure of a migration effort. Inflexibly resisting scope creep can affect customer confidence and completion of a project on time, but to try to incomplete specifications is a costly and pointless exercise.

Ideally, any migration project's scope will be the provision of equivalent end- user service or business support by way of a different platform, application, or process. Deviations from a scope should be fully documented with appropriate risks, mitigation procedures, and contingency plans as outlined in the following sections.

Understanding Risks and Planning Contingencies

Risks are inherent in any IT project. However, migrations tend to be considered the most risky because of the number of interdependencies they involve and the amount of change they produce. To minimize risk in migrations, you should follow a risk management technique. While many different techniques exist, most include the following components :

• Risk identification

• Risk estimation

• Risk evaluation

• Mitigation and contingency plan creation

By choosing a risk management technique that has each of these components, you can actively monitor and control risk.

Because of the risky nature of migration projects, it is especially important to plan for contingencies in case your project runs into trouble. A contingency plan needs to be documented and approved during project planning so that it can be executed as an option should the need arise, not as a panic response that precipitates scores of other emergencies.

The following figure illustrates how risk is decreased with knowledge gained through an assessment of the migration opportunity. At one extreme, if you know absolutely nothing about the application and the associated infrastructure, your risk is high. On the other hand, if you have invested so much time and effort into understanding the environment and implementing proofs of concept that you have already completed the bulk of the project, your risk is nonexistent. The amount of effort expended during an assessment should be directly related to the level of risk the organization is willing to accept and the associated costs it is willing to pay, both in terms of labor and organizational disruption caused by the assessment activity itself.

Figure 4-2. Risk Evaluation Rating Graph

This section explains how to identify and estimate risk in a project and how to evaluate that risk. It then presents a common risk management technique and its application to migration projects.

Identify Risk

All risks need to be stated so that they can be evaluated. There are generally two types of risk: business risk and project risk. Business risks prevent the project's ability to deliver the desired business benefits. Project risks jeopardize the project from delivering its objectives. In Chapter 1, we outlined a number of problems that can occur during a migration project. Any and all of these problems are potential business or project risks. They include the following:

• Business risks

  • Cost

  • Complexity

  • Time and effort

  • Lack of executive support

  • Resistance to change

• Project risks

  • Inappropriate scope

  • Lack of accurate information

  • Poor change control

The risks that you identify for your project should cover most of these, as well as any risks that are specific to your project, situation, or organization. It is not uncommon for complex migration projects to have dozens of risks.

Estimate Risk

Each identified risk must be assessed. This assessment measures the possible repercussions to the business or project from the identified risk. While there are many ways to perform this estimation, most methodologies use the sums of two numerical indexes to ascertain the total severity of a problem. Often, these numerical indexes relate to impact (the portion of the project the risk might affect), and severity (the level of detriment it might impose).

For example, the inability of your new tape drives to read legacy backup tapes would have a narrow impact (an impact level of one), whereas the inability to secure proper testing facilities would have a broad impact (impact level of five). Expressing the estimate as a numerical index between one and five, we might rate this situation as having an impact of four.

Each identified risk must also be categorized by the severity of its impediment to the success of the project. This too will be a numerical index representing a possible problem. In the example above, if the legacy tape drives were the only source of data and were quite rare, the inability to access them would rate as a high severity. However, because we can simply back up this data to another tape drive or across the network, we rate its severity as one.

Evaluate Risk

After identifying risks and estimating their impact and severity, you need to evaluate and prioritize the risks to your project. This task allows you to concentrate on risks that pose the greatest threat to your project. Most methodologies prioritize risks according to the product of their numerical impact and severity ratings.

Continuing with our example above, we produce the risk evaluation rating of four by multiplying the impact score of four times the severity score of one. However, if we had to rely on these tape drives and the severity rating was four, our risk evaluation rating would soar to sixteen (4 x 4 = 16). These risk evaluation ratings become very clear when they are graphed.

Create Mitigation and Contingency Plans

Once all the risks have been identified and prioritized, mitigation and contingency plans must be created. Mitigation plans reduce the risk of the problem occurring; contingency plans outline the project's recourse if the problem occurs. Some of these plans should be built into the best practices of the project itself. For example, a common risk for migration projects will be the failure to successfully port the source code to the new platform. Mitigation steps for this risk include the following:

• Involving appropriate vendors early in the process. Appropriate vendors in this case would be legacy and current platform vendors , as well as any vendor contributing source code (such as libraries).

• Contracting outside experts in this type of porting to mentor the staff involved in the project.

• Reviewing code frequently with the porting team to identify problems early.

• Porting the code "in place" through the use of macros and other programming constructs so that it compiles on both the legacy and new platforms. This allows the code, with any improvements, to be used on either platform.

However, if these mitigation efforts do not lead to a successful port, contingency plans should be available. Contingency plans for this problem might include the following:

• Outsourcing the porting tasks to a vendor skilled in such projects. The impact on the project from this approach would be cost, resources, and time.

• Revaluating strategy for the migration. For example, instead of porting the source code, you could run it under emulation technology. Or, perhaps a complete rewrite is in order. This option has broad effects on all phases of the project.

• Falling back to the legacy solution. As part of this plan, the original source code was backed up to nonwritable media and securely stored in a software library. Fallback has obvious detrimental effects to the project (possibly even ending it) but protects the business.

As you can see, contingency plans are formed at different levels, depending on the magnitude of the risk.

You should refine and update the risk and contingency methodology during each successive phase of the project. It is hoped that active monitoring will show a downward trend of these risks as the project goes forward.

Organizing the Project Team

The final piece of the migration project plan is the organization of people, their relationships, and reporting structures. While your specific project management framework will dictate many of the specifics of your general project structure, the following tips might help your migration project run smoothly.

The following figure shows a typical project organization.

Figure 4-3. Project Team

Each box within this illustration serves a specific purpose:

• Project sponsors and Project board. This group represents the business and provides overall governance to the project through its careful monitoring and evaluation of the project against the business justification and project plan.

• Project office. This team usually consists of the project manager, chief architect, and support staff. They are in charge of leading the teams , enforcing the project plan, and reporting status and progress to the project sponsors.

• Quality office and Project assurance. This team independently monitors the overall project process and outputs, and reports results to the project sponsors. This monitoring may range from simple project reviews to full-scale audits .

• Testing team. A vitally important team will test all produced solutions to ensure they technically meet the project's objectives.

• Development and Porting team. This team actually migrates the solution to the new application, process, or platform. The team will vary in size and composition depending on the migration strategy chosen .

• Data Conversion team. This team is similar to the Development and Porting team, but is solely concerned with the transformation or conversion of the legacy data for the new environment. While this team can be combined with the Development and Porting team, keeping it separate ensures the different skills and goals are properly represented.

• Infrastructure team. This team is responsible for architecting and specifying the infrastructure and platform for the newly migrated solution. As is the case with the Development and Porting team, this team's resources and skills will depend on the migration strategy attempted.

• Implementation team. This team builds, deploys, and migrates the consolidated environments. This team is usually a rotating group of subject matter experts with the skills required for the particular consolidation.

• Operations team. This team is in charge of scheduled migrations and downtime in the current environment, as well as the eventual day-to-day management of the migrated solution.

Identify Resources

After detailing tasks and durations in a project plan, you should identify the resource profiles required to complete the tasks. Resource profiles are sets of skills that are required to accomplish groups of tasks within a project plan. For example, assessing the current platform and building the new platform are two separate tasks that require similar skills. To accomplish either task, you must have access to a person who understands the hardware and operating system technologies used in a particular environment. Once you identify all of the resource profiles for a particular project, you can assign people with these profiles to individual tasks, and begin creating a project plan.

Note

The project manager and implementation team for the project should create the project plan. Although they will work closely with the engagement team to develop a plan and schedule that satisfies the business requirements and timelines , project planning is primarily a technical task and is best left to those who understand the time, skills, and efforts required.

Developing a Project Plan

Now that the project startup and initiation activities have been completed, it is time to construct a realistic project plan for your migration effort. While every migration project will be different in objectives, scope, difficulty, and level of effort, some standard steps and rules of thumb can be applied to any project plan.

This section focuses on the creation of a sample project plan, using the SunTone ^SM Architecture Methodology. Our sample migration will be a small, relatively simple migration that we are rehosting through a technology port of a custom C application that operates in conjunction with an Oracle database. The custom application is composed of about 4000 lines of code. For the sake of this example, imagine that the application was created to run in the HP-UX environment but the organization now wants to run it in the Solaris environment.

Architect a Migration Solution

Architecture is the first stage of the project that we need to tackle. In the SunTone Architecture Methodology, architecture is divided into three major areas: assessment, design, and prototyping. Each of these areas is aimed at advancing the solution toward a new design.

Assessment Activities

Assessment activities in this stage are straightforward. We need to investigate each layer of the E-stack within the solution and assess what likely changes are necessary to meet our goals of rehosting this on the Solaris OS. In terms of the project plan, we would create tasks for each layer of the E-stack, making sure that they document all the layer's important systemic requirements, possibly combining adjacent ones when necessary. We would combine layers only when we thought that a single resources could investigate that layer fully.

In our example project, we would construct a task list like the one shown in the following figure.

Figure 4-4. Example Task List

There is no set rule for the length of time needed for these assessment activities, but because this is a relatively simple migration with just two servers involved, we give each task one resource and one week to complete it. The output of each of these tasks will be a summary of the current situation, detailed information about key configuration items, and an estimation of the level of effort required to move to a new environment.

In our example project, we have divided the tasks between two roles: an application architect and a system administrator. The application architect investigates the upper levels of the E-stack, and the system administrator documents the current hardware platform.

Design Activities

With the due diligence of the assessment behind us, we can begin to concentrate on the two major tasks for the design of the new solution:

• Reviewing the data gathered during the assessment. This task is a critical part of the design, whereby the raw data is turned into usable information by identification of key requirements within the gathered data. These requirements then drive the initial design of the migrated solution.

• Developing an initial design. The initial design takes into account the requirements gleaned in the previous task and matches them with technologies in the key systemic qualities. This combination of technologies becomes the initial design of the migrated solution.

While each company will have different processes, methodologies, and standards for architectural design, the deliverable should be the same: an architectural report detailing the requirements and all components of the solution. The effort to create this deliverable will be much more variable than the preceding assessment because it fundamentally depends on the complexity of the current solution, not necessarily on its size.

For this example, we project three weeks to create the design. One week of that time is set aside for creating the requirements, and two weeks is set aside for the creation of the solution, as shown in the following example architecture schedule.

Figure 4-5. Architecture Schedule

Prototype Activities

The next activities in the architecture provide a proof of concept for the initial architecture. This is an optional step, depending on the level of risk and the project's mitigation plans. Many migration projects will include this stage, especially if they are migrating to COTS solutions. The prototype will usually take several weeks to develop and will result in the construction of a scaled-down version of the initial solution that can provide the functional validity of the solution.

In our sample project, we decide that a prototype is not necessary since the risks do not warrant the time or efforts. Because of the small scope of the project and our relative confidence in being able to port the code, it simply isn't feasible to spend the time and money necessary to complete this activity.

Implement the Migration Solution

With the architecture stage completed, it is time for implementation. In the SunTone Architecture Methodology, implementation is divided into many areas:

• Porting

• Data conversion and movement

• Building

• Testing

• Training

Each of these areas is crucial to successfully completing a migration.

Application Redevelopment and Porting Activities

In migration projects that rely on the porting or redevelopment of applications, this stage receives the most attention. Other migration projects, such as the migration from custom applications to COTS solutions, might not address it at all. These tasks include the process of developing, customizing, or porting applications so that they execute in the new environment. The key activities here include the following:

• Creating the new build environment

• Modifying the application for the new build environment

• Compiling and building the application for the new environment

• Unit testing the new application

Again, these activities vary greatly depending on complexity. However, the key criterion in this level of effort is the application or porting complexity. Some applications will require very little porting assistance; for others, porting will be a massive undertaking. This doesn't directly relate to program size, but rather to the number and difficulty of changes required.

For this example project plan, based on the assessment stage data, we believe that the porting will take a significant amount of time. We budget two months for a team of two developers.

Data Conversion and Movement Activities

Similar to the developing and porting activities, this set of tasks readies the data for the next environment. However, in addition to the possible conversion of data from one format to another, there may be substantial challenges in actually moving the data from one platform and application to another. This is especially true of databases or any other application that handles data outside the normal UNIX file constructs.

For the purpose of our sample project, we budget only a small amount of time for data conversion and movement. As the data already resides in standard SQL format within the Oracle database, no conversion will be needed, just movement to the new platform. To be on the safe side, we allot two weeks for the planning, implementation, and testing of this movement.

Build Activities

The build activities of the implementation stage are similar to those of any other project. Infrastructure must be constructed so that the applications can be hosted. Some of the environments that will need to be built include the following:

• Test environment

• Target environment

• Target platform

• Application environment

• Regression environment

In our sample project, this is a fairly simple task because the proposed solution is only one server. We allot three weeks to account for the amount of time that it takes to get onto the production floor.

Test Activities

One of the more important parts of a migration project is buried here in the middle of the project plan. Testing will make or break a migration project. Several types of tests need to be planned and executed:

• Unit testing

• Integration testing

• Validity testing

• Performance testing

• Transfer testing

We make sure to allow for ample time to test in our sample project. In fact, we give it four weeks, almost as much time as it took for development.

Training Activities

The final activities in the implementation stage address the overlooked human aspect of migration projects: training. Several levels of training will need to conducted to make sure that the newly migrated environment supports the business properly. The following types of training might be necessary:

• Solaris familiarity

• Training classes

• End-user training

Although this activity set is discussed last, it should actually be started before the build tasks within this stage so that administrators have good knowledge of the new environment.

Manage the Migrated Environment

The final stage of migration is making sure that the migrated solution will meet the previous service level agreements. We do this by addressing the operation and maintenance procedures with the same approach as for the human and technology issues in the project.

These are the key tasks in this phase:

• Evaluating operational procedures and tools

• Redeveloping subpar procedures and tools to meet expected performance

• Implementing new supporting tools

Between each stage of the project, these key project evaluation documents need to be updated and reassessed:

• Risks, mitigation, and contingency plans

• Project actuals compared against the plan

• Review of key benefits and objectives validity