Directions for using
template:
Read the Guidance
(Arial blue font in brackets) to understand the
information that should be placed in each section of this template. Then delete
the Guidance and replace the placeholder within <<Begin text here>>
with your response. There may be additional Guidance in the Appendix of some
documents, which should also be deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:
You may elect to indent sections for readability.
|
Author |
|
|
Author Position |
|
|
Date |
|
Ó 2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft
and Visual Basic are either registered trademarks or trademarks of Microsoft in
the
Change Record
|
Date |
Author |
Version |
Change Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document Properties
|
Item |
Details |
|
Document Title |
Migration Plan |
|
Author |
|
|
Creation Date |
|
|
Last Updated |
|
[Introduction to the
Template
Description:
The
Migration Plan describes the migration from existing systems or applications to
the new solution. Migration is often more important in infrastructure deployment
than application development projects, but application development projects
usually will also include some sort of migration. Information on what will be
migrated is found in the Functional Specification. The Vision/Scope document may
also provide some insight into the overall migration
strategy.
Justification:
Migration
is critical to success. Without well-tested migration paths, new solutions can
fail because legacy components introduce risks that were never accounted for
during planning. If data or functionality from legacy systems cannot be migrated
successfully to the new solution, the new solution cannot be deployed and a
return on investment cannot begin.
{Team
Role Primary: Development and
Release Management are
responsible for creating the Migration Plan. Development will write code that
enables certain aspects of the migration. Release Management needs to be familiar with the
migration plans to account for them in the Deployment and Operations Plans where
appropriate. The migration will involve some short-term activity between
different systems that may span different firewalls, operating systems and
hardware; Release Management must account for this. They will also implement the
decommissioning of legacy systems that are no longer needed. Test approves the plan and incorporates
migration tests into their Test Plans.
Team
Role Secondary:
Program Management ensures that the Migration Plan is
developed and incorporated it into the Master Project
Plan.}]
[Description:
Provide an overall summary of the contents of this
document.
Justification:
Some
readers may need to know only the highlights of the plan, and summarizing
creates that user view. It also enables the full reader to know the essence of
the document before they examine the details.]
[Description:
The Objectives and Goals section defines the primary drivers that were used to
create the migration approach and the key objectives and goals of that
approach.
Justification:
Identifying
the drivers and migration objectives signals to the customer that Microsoft has
carefully considered the situation and created an appropriate migration
approach.]
[Description:
The Business-Related Objectives section identifies the business objectives that
are driving the migration. This may include things such as better manageability,
greater scalability, improved security, and improved availability. This
information may be derived from the Vision/Scope or other appropriate
documents.]
[Description:
The Migration-Related Goals section defines the migration goals. This could be
described in categories such as the amount of disruption that will occur, impact
on security, etc.]
[Description:
The Migration Strategies section describes the one or more strategies that will
guide the migration process. These do not have to be mutually exclusive but may
describe different pieces of the overall migration. Strategy could be organized
around releases (related to the business or to development/technology maturity)
or organized around solution components. These strategies also need to consider
moving legacy systems into the new solution environment.
Justification:
Developing strategies ensures that the migration process isn’t a “one-off”
activity, that the solution and its environment are approached
strategically.]
[Description:
The Migration Strategy 1 section describes the specific elements of the solution
are that will be migrated. It describes the current and future environmental
aspects of the migration, the time frame within the overall solution, and the
sequence in which the elements will be migrated. ]
<<Begin text here>>
[Description:
The
Tools section identifies the
tools
that will be employed to support this migration strategy. These may be
installation tools, testing tools, training tools, etc., and may include tools
from third parties.]
<<Begin text here>>
[Description:
The
Implications section describes the
impacts
caused by the migration and what other things will need to occur in conjunction
with the migration in order for it to be successful. This may include training,
acquisition of hardware, changes in user environment, facilities and support,
etc.]
[Description:
The Migration Strategy 2 section describes the specific elements of the solution
are that will be migrated. It describes the current and future environmental
aspects of the migration, the time frame within the overall solution, and the
sequence in which the elements will be migrated.]
<<Begin text here>>
[Description:
The
Tools section identifies the
tools
that will be employed to support this migration strategy. These may be
installation tools, testing tools, training tools, etc., and may include tools
from third parties.]
[Description:
The
Implications section describes the
impacts
caused by the migration and what other things will need to occur in conjunction
with the migration in order for it to be successful. This may include training,
acquisition of hardware, changes in user environment, facilities and support,
etc.]
[Description:
The
Migration Environment section
provides
details on the existing and/or future environment in which the solution will
operate and the people will use the solution. It describes the current
environment (all relevant aspects) and the future environment
(hardware/software, facilities, etc).]
[Description:
The Migration Guidelines section describes what guidelines need to be followed
within this environment, such as what trust exists between domains or where user
accounts reside.
{Team
Role Primary: Test; Development; Release Management
Team
Role Secondary:
Program Management}]
<<Begin text here>>
[Description:
The Migration Process section describes how the migration will be conducted. It
includes the preparatory activities as well as the migration stages necessary to
complete the migration process. There are sub-sections for 2 stages; however,
this does not imply that the project will have only 2 – create as many as
appropriate for the project.
Justification:
Outlining the migration process ensures that migration will be conducted in a
logical and controlled manner.]
[Description
The
Test Environment section describes
the test environment(s) that, to the extent possible, replicate(s) the
production environment. This should include identification of all environmental
attributes that must be in place. There may be more than one environment – a
series of them could be phased in to control testing. An example of this is to
include users after the initial phase.
{Team
Role Primary: Test
Team
Role Secondary:
Development; Release Management}]
<<Begin text here>>
[Description:
The Preparation section identifies and describes all tasks required to prepare
for migration; acquisition, test, training, etc. It also describes the task
sequences, durations, responsibilities, and expected
results.]
[Description:
The Migration Stage 1 section describes stage 1 of the migration process. It
identifies what is migrated and in what order.]
[Description:
The Migration Stage 2 section describes stage 2 of the migration process. It
identifies what is migrated and in what order.]
[Description:
The Decommissioning of Replaced Resources section describes how existing
resources will be taken offline. This should include criteria that will
determine when and how those resources will be decommissioned.]
[Description:
The Roll Back Plan section describes how, if problems do occur, a customer can
roll back to the prior configuration.
{Team
Role Primary: Test; Development; Release Management
Team
Role Secondary:
Program Management}]
<<Begin text here>>