Creating a Project Plan

The migration project plan describes the overall migration effort by gathering detailed plans, including development, test, training, deployment, and end- user support plans, as well as the migration schedule. It should take into account the type of migration to be performed, the issues raised (and their mitigations), the funding provided, and the availability and skill sets of the resources on the migration project.

The following sections describe each detailed plan and schedule.

Development Plan

The development plan describes how the development team will migrate the application. It describes information about the tools, methodologies, best practices, sequences of events, and so on. It includes:

• Design goals (for example, components , services, and technologies of the solution from the development team s perspective).

• Coding strategy (for example, rewrite vs. port, standards, tools, code reuse, libraries, things to avoid, portability, and testability).

• Programming model, which:

  • Prescribes how the selected technologies will be used.

  • Sets design guidelines as the design foundation for component specification; this helps to ensure consistency across the project.

  • Uses different considerations to address different aspects of the solution.

  • Provides a baseline for identifying potential technical risks.

• Design and code review strategy (for example, comprehensive, formal review; casual, peer-based review; and independent, third-party review).

• Source control strategy (for example, project file structure, version numbering convention, releases naming, installation programs/scripts, and Help files).

• Build strategy, which includes:

  • How (automated and/or manual, make structure), when, and in what frequency (should be performed on a regular and frequent basis).

  • The person or group responsible for the build.

  • Testing and feedback on the health of the build.

  • Whether the build strategy will be linked with progress monitoring.

  • The constraints on application builds.

• Integration strategy, which includes how the different components will be integrated and how their capabilities (functionalities) will evolve , for example:

  • Identify an optimal order in which to integrate the different modules and components.

  • Coordinate the integration order with the construction order so that modules and components are ready for integration at the right time.

  • Define the integration strategy to facilitate the diagnosis of defects.

  • Verify the components specification to ensure smooth integration.

Test Plan

The test plan includes a testing strategy, the specific areas to be tested , and the resources (hardware and people) that the test team requires to do its job. The various categories of tests include:

• Coverage testing (used primarily during the development phase).

• Testing every feature of the product (for example, functional test).

• Testing the code base of the product (for example check-in, build verification, and regression tests).

• Usage testing (used primarily during the stabilizing phase).

• Integration testing (used to verify the correct interactions between components and other systems). For integration testing, the test plan should cover:

  • Synchronization and coordination between components (for example, UNIX and Windows workstation data access by the migrated application).

  • Data integrity ( especially when intensive file record-locking is required).

  • Features.

  • Usage scenarios.

For more information about application testing and the test plan, see Chapter 12, Testing the Migration.

Training Plan

The training plan includes a strategy and a plan for developing any necessary training materials for end users, administrators, and support personnel. It includes a document that describes the training to be provided to members of the team to ensure that they have the capabilities to support the development and deployment process. The training plan defines training objectives and the audience; it also provides a training schedule that must be incorporated into the overall project schedule. The plan also describes the training vehicles, materials, and resources.

Deployment Plan

The deployment plan includes a strategy and a detailed plan that can be used to prepare end users and operations personnel before and during deployment. It includes a document that describes all steps of the deployment process and details about the planning, organization, and realization of:

• Installation strategy.

• Deployment mechanisms.

• Resources.

• Contingency plans.

• Site survey.

• Systems support.

Support Plan

The end-user support plan includes a strategy and details for developing a document that identifies the resources, processes, and skills needed to ensure proper use of the system. It describes the different elements of user support provided, which might include one or more of the following types of support:

• Reference manuals.

• Online Help.

• Online tutorials.

There will be interdependencies between the support plan and the training plan, because some of the materials may be the same.

Migration Schedule

A migration schedule can have several components. These can be technical, business- related , or organizational in nature. Common things to consider include:

• Windows versions.

• Independent software vendor (ISV) release schedules.

• Hardware lease expirations.

• Hardware availability.

• Resource availability.

• Customer reorganizations.

Keeping all of these dependencies in mind, visible project milestones need to be established. Clear metrics should be established for each milestone, with a post mortem review performed after each milestone.

Table 5.3 illustrates an example migration schedule.

 

Each milestone should have a fixed date to keep the focus on the current task. A UNIX to Windows migration often needs a jumpstart to get moving. You should pay extra attention in the early stages until the migration gains the momentum to see it through to the finish.