Windows Server 2008 R2 Unleashed (22 page)

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 iden-

tified. 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

68

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

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 implementa-

tion, 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 soft-

ware 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

ptg

that does not necessarily need to be placed in the project plan (Gantt chart), the informa-

tion can be detailed in the migration document. The migration document adds in techni-

cal 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 pro-

ject 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.

The Migration Planning Phase: Documenting the Process for Migration

69

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.

2

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 envi-

ronment 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 infor-

ptg

mation 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 strate-

gies 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:

. Executive Summary

. Goals and Objectives of the Migration Process

. Background

. Risks and Assumptions

. Roles and Responsibilities

. Timeline and Milestones

. Training Plan

70

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

. Migration Process

. Hardware and Software Procurement Process

. Prototype Proof of Concept Process

. Server Configuration and Testing

. Desktop Configuration and Testing

. Documentation Required from Prototype

. Pilot Phase(s) Detailed

. Migration/Upgrade Detailed

. Support Phase Detailed

. Support Documentation Detailed

. Budget Estimate

. Labor Costs for Prototype Phase

. Labor Costs for Pilot Phase

. Labor Costs for Migration/Upgrade Phase

ptg

. Labor Costs for Support Phase

. Costs for Training

. Project Schedule

The Executive Summary Section

The executive summary should set the stage and prepare the audience for what the docu-

ment 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 docu-

ment 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

The Migration Planning Phase: Documenting the Process for Migration

71

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 summa-

rizing them early in the document for anyone who wasn’t involved in those conversations.

The Risks and Assumptions Section

2

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 docu-

ment 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 identi-

fied 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

ptg

Specific target dates can be listed, and should be available directly from the project sched-

ule 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

72

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

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 docu-

ment, 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