Creating the Migration Document
With the Design document completed and agreed to by the decision makers, the Migration document can now be created. There are always different ways to reach the desired Exchange Server 2010 configuration, and the Migration document presents the method best suited to the needs of the organization in terms of timeline, division of labor, and costs. Just like the Design document, the migration plan is based on the goals and objectives defined in the initiation and planning processes. The Migration document makes the project real; it presents specific information on "who does what" in the actual testing and migration process, assigns costs to the resources as applicable, and creates a specific timeline with milestones and due dates. Having accurate information in the migration timeline will make it much easier to ensure that resources, both people and hardware/software, are available in time.
The Migration document should present enough detail about the testing and upgrade process that the resources performing the work have guidance and understand the purpose and goals of each step. The Migration document is not a step-by-step handbook of how to configure the servers, implement the security features, and move mailboxes. The Migration document is still fairly high level, and the resources performing the work need real-world experience and troubleshooting skills.
Additional collaborative meetings might be needed at this point to brainstorm and decide both on the exact steps that will be followed and when the testing and upgrade will be. It is critical to plan the migration as carefully as possible and to always make the decisions that support the goals of the migration process. Remember, the primary goal of the migration isn't just to put a new system into place; your users won't appreciate the new functionality of Exchange Server 2010 if it was a painful process for them to get there.
Part V of this book, "Migrations and Coexistence with Exchange Server 2010," provides additional information about the various strategies and processes for moving from previous versions of Exchange Server to Exchange Server 2010.
The Project Schedule
A project schedule or Gantt chart is a standard component of the Migration document, and it presents tasks organized by the order in which they need to be completed, in essence creating a detailed road map of how the organization will get from the current state, test the solution, and then implement it.
Other important information is included in the project schedule, such as resources assigned to each task, start dates and durations, key checkpoints, and milestones. Milestones by definition have no duration and represent events such as the arrival of hard-ware items, sign-off approval on a series of tasks, and similar events. Some additional time should be allocated (contingency time) if possible during the testing phase or between phases, in case stumbling blocks are encountered. This reduces the chances of having to shift the entire project back and potentially throw off the availability of resources.
A good rule of thumb is to have each task line represent at least four hours of activities; otherwise, the schedule can become too long and cumbersome. Another good rule is that a task should not be less than 1% of the total project, thus limiting the project to 100 lines. The project schedule is not intended to provide detailed information to the individuals performing the tasks, but to help schedule, budget, and manage the project. Tracking the completion of the project plan items versus time is a great way to quickly spot when you are at risk of falling behind and compromising the timeline.
To create a project schedule, a product such as Microsoft Project is recommended, which facilitates the process of starting with the high-level steps and then filling in the individual tasks. The high-level tasks should be established first and can include testing the server configurations and desktop designs and performing one or more pilot implementations, the upgrade or migration process, and the support phase.
Dependencies can also be created between tasks to clarify that Task 40 needs to be completed before Task 50 can start. A variety of additional tools and reports are built in to see whether resources are overburdened (for example, being expected to work 20 hours in one day), which can be used for resource leveling. A baseline can also be set, which represents the initial schedule, and then the actual events can be tracked and compared to the baseline to see whether the project is ahead or behind schedule.
Microsoft Project is also extremely useful in creating budgetary information and creating what-if scenarios to see how best to allocate the organization's budget for outside assistance, support, or training.
If the timeline is very short, the Gantt chart can be used to see if multiple tasks take place simultaneously or if this will cause conflicts.
Create the Migration Document
With the project schedule completed, the Migration document will come together quite easily because it essentially fills out the "story" told by the Gantt chart. Typically, the Migration document is similar to the structure of the Design document (another reason why many organizations want to combine the two), but the Design document relates the design decisions made and details the end state of the upgrade, and 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
- Summary of Migration-Specific Decisions
- Risks and Assumptions
- Roles and Responsibilities
- Timeline and Milestones
- Training Plan
- 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
- Labor Costs for Prototype Phase
- Labor Costs for Pilot Phase
- Labor Costs for Migration/Upgrade Phase
- Labor Costs for Support Phase
- Costs for Training
The following sections delve into the information that should be covered in each section. Part V of this book provides in-depth information on the steps involved in migrating to Exchange Server 2010 from Exchange Server 2003 or Exchange Server 2007.
As with the Design document, the executive summary section summarizes what the Migration document covers, the scope of the project, and the budget requested. Again, keep in mind your audience for this summary and what they would be interested in. Avoid being too technical is this summary, focus on the high level of what they are getting from this project and when then can expect to get it.
Goals and Objectives of the Migration Process
The goals and objectives of the migration overlap with those of the overall project, but should focus also on what the goals are for use and development of internal resources and the experience of the user community. A goal of the overall project could be "no interruption of messaging services," and this would certainly be a goal to include in the Migration document. This is one of the reasons that many project management methodologies recommend always having an "end-user advocate" for this type of project.
Sub-phases of the Migration document have their own specific goals that might not have been included in the Design document. For example, a primary goal of the prototype phase, which takes place in a lab environment so it won't interfere with the production network, is to validate the design and to test compatibility with messaging-related applications. Other goals of the prototype phase can include hands-on training for the migration team, creating documents for configuration of the production servers, and creating and validating the functionality of the desktop configurations.
A summary of the migration-specific decisions should be provided to answer questions such as: "Why are we doing it that way?" 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.
Risks and Assumptions
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, therefore, need upgrading. Custom-designed messaging applications or Exchange Server add-ons might turn out not to be Exchange Server 2010 compatible.
Roles and Responsibilities
The Design document focuses on the high-level "who does what"; the Migration document should be much more specific because the budget for labor services is part of this deliverable. Rather than just defining the roles (such as project sponsor, Exchange Server 2010 design specialist, Exchange Server 2010 technical lead, and project manager), the Migration document specifically indicates the level of involvement of each resource throughout the prototype, pilot, and migration phases. The project sponsor should stay involved throughout the process, and regular project status meetings keep the team on the same page. At this point, everyone involved in the project should know exactly what they are and are not responsible for doing.
The project manager is expected to keep the project on time, on budget, and within scope, but generally needs support from the project sponsor and key stakeholders involved in the project. Depending on how the project manager role is defined, this individual might be either a full-time resource, overseeing the activities on a daily basis, or a part-time resource, measuring the progress, ensuring effective communications, and raising flags when needed. A cautionary note: Expecting the project manager to be a technical resource such as the Exchange Server 2010 technical lead can lead to a conflict of interest and generally does not yield the best results. Projects tend to be more successful if even 10% of an experienced project manager's time can be allocated to assist.
Timeline and Milestones
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.
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 happens during the proto-type 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. Ask yourself if the end users 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 need any training specific to interact with Exchange Server 2010 components.
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 an Exchange server needs to be configured, and in the Migration document, information would be added about which service pack is to be used for the NOS and for Exchange Server, 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 Outlook 2007 on sales workstation," 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 Office should be loaded, how the workstation is 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 to email, voice mail access, BlackBerry and personal information managers, and public folders. Be aware that pilot testing might require external coordination. For example, if you are testing access through OWA in Exchange Server 2010, 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 OWA systems.
The migration plan should also account for support tasks that need to occur after the Exchange Server 2010 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 Exchange Server 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.
At this point in the process, the budgetary numbers should be within 10%--20% of the final costs, bearing in mind any risks already identified that could affect the budget. Breaking the budget into prototype, pilot, migration, support, and training sections helps the decision makers understand how the budget will be allocated and make adjustments if needed. No matter how much thought has gone into estimating the resources required and risks that could affect the budget, the later phases of the project might change based on the outcome of the prototype phase or the pilot phase.
Planning, Prototyping, Migrating, and Deploying Exchange Server 2010
Initiating an Exchange 2010 upgrade: identifying goals
Using an Exchange Server 2010 design document for upgrades
Using a migration document for Exchange Server 2010
Exchange Server 2010 upgrade: Prototype, pilot phases
Printed with permission from Sams Publishing. Copyright 2009. Exchange Server 2010 Unleashed by Rand Morimoto, Michael Noel, Chris Amaris, Andrew Abbate and Mark Weinhardt. For more information about this title and other similar books, please visit Sams Publishing.
This was first published in April 2010