Before
the migration document is created, the end state of the project has
been documented in detail and agreed upon by the key stakeholders in the
organization. There should not be any question as to exactly what the
next evolution of the network will be composed of and what functionality
it will offer. In addition, an estimated budget for the hardware and
software required and an estimated timeline for the project have been
identified. In some cases, depending on the size and complexity of the
project, and whether outside consulting assistance has been contracted, a
budget has also been established for the implementation services.
So, now that the end state
has been clearly defined, the migration document can be created to
document the details of the steps required to reach the end state with
minimal risk of negative impact to the network environment.
The migration plan should not contain any major surprises.
A key component of the
migration document is the project plan, or migration plan, that provides
a list of the tasks required to implement the solution. It is the road
map from which the migration document will be created. The migration
document will also provide a narrative, where needed, of the specifics
of the tasks that the project plan does not provide, and provide other
details as outlined next.
Time for the Project Plan
As mentioned
previously, the primary stepping stones needed to reach the end point
have been sketched out in the discovery process, and in collaboration
sessions or design discussions that have taken place. The project plan
in the migration document provides a tool to complement the design
document, which graphically illustrates the process of building and
testing the technologies required as well as provides an outline of who
is doing what during the project.
By using a product such as
Microsoft Project, you can organize the steps in a logical, linear
process. The high-level tasks should be established first. Typically,
they are the phases or high-level tasks involved in the project, such as
lab testing, pilot implementation, production implementation, and
support. Then, the main components of these tasks can be filled in.
Dates and durations should be
included in the project plan, using the basic concept of starting with
the end date when everything needs to be up and running, and then
working backward. It’s important to include key milestones, such as
acquiring new software and hardware, sending administrative resources to
training classes, and provisioning new data circuits. Slack time should
also be included for unexpected events or stumbling blocks that might
be encountered. Each phase of the project needs to be outlined and then
expanded.
A good rule of thumb is not to
try to list every task that needs to take place during the phase, but
to have each line represent several hours or days of work. If too much
detail is put into the project plan, it quickly becomes unmanageable.
For the detailed information that does not necessarily need to be placed
in the project plan (Gantt chart), the information can be detailed in
the migration document. The migration document adds in technical and
operational details that will help clarify more specific project
information.
Note
The terms project plan and Gantt chart
are commonly interchanged in IT organizations and might have different
meanings to different individuals. In this book, the term project plan
refers to the chronological steps needed to successfully plan, prepare,
and implement Windows Server 2008 R2. The term Gantt chart is used to
refer to the chronological steps, but also the inclusion of resource
allocation, start and end dates, and cost distribution.
The plan should also assign
resources to the tasks and start to define the teams that will work on
the different components of the project. If an outside organization is
going to assist in the process, it should be included at the appropriate
points in the project. Microsoft Project offers an additional wealth of
features to produce reports and graphical information from this plan;
they will prove extremely helpful when the work starts. Also, accurate
budgetary information can be extracted, which can take into account
overtime and after-hours rates and easily give what-if scenario
information.
Speed Versus Risk
The
project plan will also enable you to test what-if scenarios. When the
high-level tasks are defined, and the resources required to complete
each task are also defined, you can easily plug in external contractors
to certain tasks and see how the costs change. After-hours work might
take place during working hours in certain places.
If the timeline still isn’t
acceptable, tasks can be stacked so that multiple tasks occur at the
same time, instead of one after the other. Microsoft Project also offers
extensive tools for resource leveling to make sure that you haven’t
accidentally committed a resource to, for example, 20 hours of work in 1
day.
The critical path of the project
should be defined as well. Certain key events will need to take place
for the project to proceed beyond a certain point. Ordering the hardware
and having it arrive will be one of these steps. Getting stakeholder
approval on the lab environment and proving that key network
applications can be supported might be another. Administrative and
end-user training might need to happen to ensure that the resulting
environment can be effectively supported.
You might need to
build contingency time into the project plan as well. Hardware can get
delayed and take an extra week or two to arrive. Testing can take
longer, especially with complex configurations and when customization of
the NOS is required or directory information needs to be modified.
Creating the Migration Document
The migration document can
now narrate the process detailed in the project plan. The project plan
does not need to be 100% complete, but the order of the steps and the
strategies for testing and implementing will be identified. Typically,
the migration document is similar to the structure of the design
document (a reason why many organizations combine the two documents),
but the design document relates the design decisions made and details
the end state of the upgrade, whereas the migration document details the
process and steps to be taken.
The following is a sample table of contents for the migration document:
The Executive Summary Section
The executive summary should
set the stage and prepare the audience for what the document will
contain, and it should be concise. It should outline, at the highest
level, what the scope of the work is. Ideally, the executive summary
also positions the document in the decision-making process and clarifies
that approvals of the design are required to move forward.
The Goals and Objectives Section
The goals and
objectives section might seem redundant because the design documents
documented the objectives in great detail, but it is important to
consider which specific goals and objectives are important to the
success of the migration project that might not have been included in
the design document. For example, although the design document outlined
what the final server configuration will look like, it might not have
outlined the tools needed to migrate key user data or the order that the
company offices will be migrated. So, the goals and objectives in the
migration document will be very process specific.
The Background Section
A summary of the
migration-specific decisions should be provided to answer questions such
as “Why are we doing it that way?” because there is always a variety of
ways to implement
new messaging technologies, such as using built-in tools as opposed to
using third-party tools. Because a number of conversations will have
taken place during the planning phase to compare the merits of one
method versus another, it is worth summarizing them early in the
document for anyone who wasn’t involved in those conversations.
The Risks and Assumptions Section
Risks pertaining to
the phases of the migration should be detailed, and typically are more
specific than in the design document. For example, a risk of the
prototype phase might be that the hardware available won’t perform
adequately and needs to be upgraded. Faxing, virus protection, or backup
software might not meet the requirements of the design document and,
thus, need upgrading. Custom-designed messaging applications or Windows
add-ons might turn out not to be Windows Server 2008 R2 compatible.
The Roles and Responsibilities Section
In the roles and
responsibilities section, the teams that will do the work should be
identified in detail. If an outside company will be performing portions
of the work, which tasks it will be responsible for and which ones
internal resources will take ownership of should be documented.
The Timeline and Milestones Section
Specific target dates can be
listed, and should be available directly from the project schedule
already created. This summary can be very helpful to executives and
managers, whereas the Gantt chart contains too much information.
Constraints that were identified in the discovery process need to be
kept in mind here because there might be important dates (such as the
end of the fiscal year), seasonal demands on the company that black out
certain date ranges, and key company events or holidays. Again, be aware
of other large projects going on in your environment that might impact
your timeline. There’s no point trying to deploy new servers on the same
weekend that the data center will be powered off for facility upgrades.
The Training Plan Section
It is useful during the
planning of any upgrade to examine the skill sets of the people who will
be performing the upgrade and managing the new environment to see if
there are any gaps that need to be filled with training. Often, training
will happen during the prototype testing process in a hands-on fashion
for the project team with the alternate choice being classroom-style
training, often provided by an outside company. Also ask yourself if the
end users will require training to use new client-side tools. Also pay
attention to how the new environment will integrate into existing
systems such as backup or monitoring. Determine if those groups will
need any training specific to interacting with Windows Server 2008 R2
components.
The Migration Process Section
The project schedule Gantt
chart line items should be included and expanded upon so that it is
clear to the resources doing the work what is expected of them. The
information does not need to be on the level of step-by-step
instructions, but it should clarify the process
and results expected from each task. For example, the Gantt chart might
indicate that a Windows Server 2008 R2 server needs to be configured,
and in the migration document, information would be added about which
server roles need to be installed, how the hard drives are to be
configured, and which additional applications (virus protection, tape
backup, faxing, network management) need to be installed.
If the Gantt chart lists a task
of, for example, “Configure and test Windows client access,” the
migration document gives a similar level of detail: Which image should
be used to configure the base workstation configuration, which
additional applications and version of Windows should be loaded, how is
the workstation to be locked down, and what testing process should be
followed (is it scripted or will an end user from the department do the
testing)?
Documentation also should
be described in more detail. The Gantt chart might simply list “Create
as built documents,” with as built defined as “document containing key
server configuration information and screenshots so that a knowledgeable
resource can rebuild the system from scratch.”
Sign-off conditions for the
prototype phase are important and should be included. Who needs to sign
off on the results of the prototype phase to indicate that the goals
were all met and that the design agreed upon is ready to be created in
the production environment?
Similar levels of information
are included for the pilot phase and the all-important migration
itself. Typically during the pilot phase, all the upgraded functionality
needs to be tested, including remote access, file encryption access,
and access to shared folders. Be aware that pilot testing might require
external coordination. For example, if you are testing remote access
through a VPN connection, you might need to acquire an additional
external IP address and arrange to have an address record created in DNS
to allow your external testers to reach it without having to disturb
your existing remote access systems.
The migration plan should
also account for support tasks that need to occur after the Windows
Server 2008 R2 infrastructure is fully in place. If you are using an
outside consulting firm for assistance in the design and implementation,
you should make sure that they will leave staff onsite for a period of
time immediately after the upgrade to be available to support user
issues or to troubleshoot any technical issues that crop up.
If documentation is
specified as part of the support phase, such as Windows maintenance
documents, disaster recovery plans, or procedural guides, expectations
for these documents should be included to help the technical writers
make sure the documents are satisfactory.
The Budget Section
With regard to the budget
information, although a great amount of thought and planning has gone
into the design and migration documents, as well as the project plan,
there are still variables. No matter how detailed these documents are,
the later phases of the project might change based on the results of the
earlier phases. For instance, the prototype testing might go
flawlessly, but during the pilot implementation, performing data
migration simply takes longer than anticipated; this extra time will
require modifications to the amount of time required and the associated
costs. Note that changes in the opposite direction can happen as well,
if tasks can occur more quickly than anticipated. Often, the implementation costs can be reduced by keeping an eye on ways to improve the process during the prototype and pilot phases.
The Project Schedule Section
Whereas the project plan
provides the high-level details of the steps, or tasks, required in each
phase, the approach sections of the migration document can go into more
detail about the details of each step of the project plan, as needed.
Certain very complex tasks are represented with one line on the project
plan, such as “Configure Windows Server 2008 R2 #1” and might take
several pages to describe in sufficient detail in the migration
document.
Data availability testing
and disaster recovery testing should be discussed. In the design
document, you might have decided that clustering will be used, as well
as a particular tape backup program, but the migration plan should
outline exactly which scenarios should be tested in the prototype lab
environment.
Documents to be provided during the migration should be defined so that it is clear what they will contain.
