To start the organizational process, it is helpful to break up business goals and objectives into different levels, or vantage points. Most organizations have high-level business goals, often referred to as the “vision of the company,” which are typically shaped by the key decision makers in the organization (such as the CEO, CFO, CIO, and so on); these goals are commonly called the “50,000-foot view.” Business unit or departmental goals, or the “10,000-foot view,” are typically shaped by the key executives and managers in the organization (such as the VP of Sales, HR Director, Site Facilities Manager, and so on). Most organizations also have well-defined “1,000-foot view” goals that are typically very tactical in nature, implemented by IT staff and technical specialists.

It is well worth the time to perform some research and ask the right questions to help ensure that the networking system implementation will be successful. To get specific information and clarification of the objectives of the different business units, make sure the goals of a technology implementation or upgrade are in line with these business goals.

Although most organizations have stated company visions and goals, and a quick visit to the company’s Web site or intranet can provide this information, it is worth taking the time to gather more information on what the key stakeholders feel to be their primary objectives. Often this task starts with asking the right questions of the right people and then opening discussion groups on the topic. Of course, it also matters who asks the questions, because the answers may vary accordingly, and employees may be more forthcoming when speaking with external consultants as opposed to co-workers. Often the publicly stated vision and goals are “the tip of the iceberg” and may even be in contrast to internal company goals, ambitions, or initiatives.

High-level business goals and visions can vary greatly between different organizations, but generally they bracket and guide the goals of the units that make up the company. For example, a corporation might be interested in offering the “best” product in its class, and this requires corresponding goals for the sales, engineering, marketing, finance, and manufacturing departments. Additional concepts to look for are whether the highest-level goals embrace change and new ideas and processes, or want to refine the existing practices and methods.

High-level business goals of a company can also change rapidly, whether in response to changing economic conditions or as affected by a new key stakeholder or leader in the company. So, it is also important to get a sense of the timeline involved for meeting these high-level goals.

When the “vision” or “50,000-foot view” is defined, additional discussions should reveal the goals of the different departments and the executives who run them. Theoretically, they should “add up” to the highest-level goals, but the findings may be surprising. Whatever the case turns out to be, the results will start to reveal the complexity of the organization and the primary concerns of the different stakeholders.

The high-level goals of the organization also start to paint the picture of which departments carry the most weight in the organization, and will most likely get budgets approved, and which will assist in the design process. Logically, the goals of the IT department will play a very important role in a network operating system (NOS) migration project, but the other key departments shouldn’t be forgotten.

As an example of the business unit or departmental goals for an organization, an HR department may typically influence the decision for right-to-privacy access to core personnel records. Or a legal department may typically influence security access on information storage rights and storage retention.

If the department’s goals are not aligned with the overall vision of the company, or don’t take into account the needs of the key stakeholders, the result of the project may not be appreciated. “Technology for technology’s sake” does not always fulfill the needs of the organization and in the long run is viewed as a wasteful expenditure of organizational funds.

In the process of clarifying these goals, the features of the network operating system and network applications that are most important to the different departments and executives should become apparent. It is safe to assume that access to company data in the form of documents or database information, and to communications tools such as email, faxing, and Internet access, and to the vertical market software applications that the company relies upon will affect the company’s ability to meet its various business goals.

The Sales department will most likely have goals that require a specific client relationship management (CRM) application as well as access to key company data and communications tools. Likewise, the Finance department will have applications that track specific AR and AP information and that most likely tie into applications used by other departments. The IT department will have its key technologies that support the applications in use, store and maintain the company’s data, and manage key servers and network devices.

It is also worth looking for the “holes” in the goals and objectives presented. Some of the less glamorous objectives, such as a stable network, data recovery abilities, or protection from the hostile outside world, are often neglected.

A by-product of these discussions will ideally be a sense of excitement over the possibilities presented by the new technologies that will be introduced, and will convey to the executives and key stakeholders that they are involved in helping to define and craft a solution that takes into account the varied needs of the company. Many executives look for this high-level strategy, thinking, and discussions to reveal the maturity of the planning and implementation process in action.

By now, the list of goals and objectives may be getting quite long. But when the myriad of business and technical objectives as well as the overall priorities start to become clear, the scope of work starts to take shape. A key question to ask at this point, to home in on the scope of the project, is whether the migration is primarily an operating system upgrade or an application upgrade. Often the answer to this question seems clear at first but becomes more complex as the different goals of the business units are discussed, so the scope of work that is created may be quite different than it appeared at first.

Specifically, a decision needs to be made whether the entire network operating system (NOS) needs to be upgraded or only a subset of it, and what other infrastructure components need to be changed or replaced. This section focuses on the server components, but later chapters will focus on other hardware and software areas that should be reviewed.

Upgrading to the latest version of a key network application (CRM solution, document management system, or remote access solution) may require a network operating system upgrade, but it may need to involve only a limited portion of the network (perhaps only one server). Yet if this application needs to be accessed by every member of the organization, in several offices, and requires upgrades to data storage solutions, tape backup software, antivirus software, remote access, and connectivity between offices, a full NOS upgrade may make more sense. An upgrade Windows Server 2003 enterprisewide can allow centralization of resources, consolidation of servers, enhanced management tools, and other features that may make a larger project more attractive.

It is important to also examine how the business and technology goals fit into this plan. If one of the goals of the organization is 99.99% uptime during business hours, this may well affect the migration process and limit changes to the network to weekends or after hours. Or a goal that involves a dramatically short timeline may likewise affect the strategy and require a partial NOS upgrade.

Questions raised at this point may require further discussion and even research. The section, “The Discovery Phase: Understanding the Existing Environment” later in this chapter examines some areas that generally need review. But with a solid understanding of the different departmental and companywide goals for the project, you can sketch out a basic outline of the required configuration.

You need to get answers to these sample questions:

Based on the goals and objectives for the project and the answers to these types of questions, the high-level scope of the work begins to take shape. Here are some general rules to consider:

Often it makes sense to upgrade the operating system first; then add directory services and file and print functionality; and finally ensure the system is properly protected with a compatible backup solution, virus protection, and disaster recovery plan. When this foundation is in place, the applications can be migrated in a more gradual process. In other cases, the new application must be installed in advance of the operating system upgrade, for testing purposes, or because of budget limitations or a tight timeline.

Implementing the latest version of Exchange is a good example; this implementation requires not only a core operating system upgrade (to Windows 2000 or Windows Server 2003) but also requires that the Windows Active Directory is properly implemented. On the other hand, for an organization implementing SharePoint Team Services (STS), because STS does not require Active Directory to make the application fully functional, the organization can choose to implement just Windows Server 2003 as an application server and can delay the implementation of Active Directory or other Windows Server 2003 services to a future date.

Note, however, that if the NOS in use is too old or no longer supported by the manufacturer, the upgrade choices might be limited. You may simply have to implement a completely new collection of servers with compatible network applications and phase out the old ones.

Often an application-focused upgrade will introduce a limited number of new servers but also set the stage for the eventual migration. But this can be an effective way to implement the new technology in a faster method than an enterprisewide operating system upgrade. A partial upgrade also may defer the costs of purchasing new server licenses, client access licenses, and other enterprisewide applications, including virus protection and tape backup. Ideally, the servers that are upgraded for the new application(s) should be designed to integrate into the NOS after a full-fledged upgrade. In other words, ideally these servers won’t need to be rebuilt later.

As will be discussed in Chapter 8, “Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories,” Windows Server 2003 is designed for compatibility and co-existence with a variety of other network operating systems in addition to NT Server and Windows 2000 servers. An important point to consider during the design process is whether it makes sense to upgrade the entire NOS even though doing so may not be absolutely essential. There may be convincing arguments for a complete upgrade because management of a uniform environment can be easier to administer organization-wide, and an upgrade Windows Server 2003 may solve a number of existing issues.

Again, the answers may not be obvious at this point in the design process. But by asking the questions and engaging in “what if” discussions and speculations, the primary pieces of the puzzle can be identified. The next step is to determine how best to fit those pieces together.

An equally important component of the migration is the time frame, and this component will affect the path and process that needs to be followed to create the results desired. Often the goals for the project will dictate the timeline, and the technology upgrade can drastically affect other critical business project dependencies. Other upgrades may not have strict timelines, and it is more important that the process be a smooth one than a quick one.

Dependent on the scope of the project, a time frame of two to four months could be considered to be a short time frame, with four to six months offering a more comfortable window. Within these time constraints, several weeks are available for discovery and design, a similar amount of time is available for the testing process, and then the implementation can proceed.

A fundamental point to remember is that change will bring with it a learning curve to both the user communities and the administrative staff. And the greater the amount of change that employees need to adjust to, the more support and training will be required to ensure their productivity when the new platform is rolled out. This is especially true when the applications change along with the operating system.

A safe strategy to take when sketching out the timeline is to start by setting a completion date and then working backward from it, to get a sense for the time available to each component of the process. As this chapter discusses, the project has several key phases—discovery, design, prototype, and implementation—and sufficient time should be allowed for each one of them. Although there are no hard and fast rules of how the time should be split up between each of these phases, each phase tends to take longer than its predecessor, and the discovery and design phases typically take as long, combined, as the testing phase (that is, discovery + design = prototype time frame).

The implementation phase will vary tremendously based on the scope of the project. For simpler projects, where the implementation consists only of a new server housing a new application, the implementation may be as simple as “flipping a switch” over a weekend (assuming the solution has been thoroughly tested in the lab environment). At the other end of the spectrum, a full NOS upgrade, happening in several locations, with changes required on the desktop, can take a period of months or quarters.

Even when the deadline for the completion of the project is the infamous “by yesterday,” time should be allocated for the design and planning process. If time and energy are not invested at this point, the prototype testing process may be missing the mark because it may not be clear exactly what is being tested, and the implementation may not be smooth or even successful. A good analogy here is that of the explorer who sets off on an adventure without planning what should go in her backpack or bringing a map along.

Slower, phased migrations typically occur when the existing environment is fairly mature and stable, and the vertical applications are still fairly current and meet the company’s needs.

Slower time frames should allow a period of weeks or months for the staff to fully understand the goals of the project and requirements of the key stakeholders, review the existing environment, and document the design. Time will also be available to choose the right partner for the project, train the internal resources who will assist in (or lead) the process, and prototype the solution in a safe lab environment. Assuming the testing is successful, a phased implementation can further limit the risks of the project, and the pilot phase of the implementation will allow the staff to learn lessons that will smooth out the remaining phases.

Milestones should be set for the completion of the phases, even if they aren’t essential to the project’s success, to keep momentum going and to avoid the “never-ending project.” Projects without periodic dates set as interim milestone points will almost certainly not meet an expected completion date. Projects that extend too far beyond the allotted time frame add costs and risks such as employee turnover, changing business conditions, and new revisions of hardware and software products.

Naturally, projects with shorter timelines bring their own challenges, and typically some compromises need to be made to successfully complete a large project in a limited amount of time. However, it is important not to abandon the basic principles of discovery, design, and testing. If these steps are skipped and an upgrade is kicked off without planning or a clear understanding of the desired results, the result will more often than not be flawed. In fact, the result may never even be reached because “show stoppers” can suddenly appear in the middle of the project.

It is usually possible to meet a quick timeline (a number of weeks at the very least) and have the results make the stakeholders happy. The real key is to understand the risks involved in the tight time frame and define the scope of the project so that the risks are controlled. This might include putting off some of the functionality that is not essential, or contracting outside assistance to speed up the process and leverage the experience of a firm that has performed similar upgrades many times.

Hardware and software procurement can also pose delays, so for shorter time frames, they should be procured as soon as possible after the ideal configuration has been defined. Note that often the “latest and greatest” hardware—that is, the fastest processors and largest-capacity drives—may take longer to arrive than those a step down. The new equipment should still be tested or “burned in,” in a lab environment, and fine-tuned, but can often be moved right into production with the pilot implementation. For most medium and large organizations, it is recommended that a permanent lab be set up; this step will be discussed in more depth in the section, “The Prototype Phase: Creating and Testing the Plan” later in this chapter.

Division of labor is a key component of the implementation process. Organizations should evaluate the capabilities of their internal staff and consider hiring an outside firm for assistance in the appropriate areas. If the organization understands and defines the roles that internal staff can play, as well as defines the areas where professional assistance is needed, the project will flow more smoothly.

The experience levels of the existing resources should be assessed, as well as the bandwidth that they have available for learning new technologies or participating in a new project. If the staff is fully occupied on a daily basis supporting the user base, it is unlikely that they will be able to “make more time” to design and plan the new implementation, even with outside assistance. The track record of the existing staff often reveals how the next project will turn out, and if there are existing half-finished or unsuccessful projects, they can interfere with a new project.

While classroom-style training and manufacturer-sponsored training do not guarantee expertise, they do indicate the IT staff’s willingness to learn and illustrate that they are willing to dedicate time to learning new technologies. A new implementation can be a great opportunity to test the commitment levels of the existing staff and also to encourage them to update their skills.

Consider also how the changes to the environment will affect the complexity of the environment that will need to be supported. For example, an upgrade Windows Server 2003 may enable a company to consolidate and reduce the number of servers on the network and replace “flaky” applications with more stable ones. An upgrade may also introduce brand-new tools that may add support duties in unfamiliar areas to the existing staff.

After the organization takes an inventory of resources at this level and determines roughly what percentage of the project can be handled internally, an external partner should be considered. Even a smaller organization faced with a relatively simple project of, say, installing a Windows Server 2003 handling one new application can benefit from outside assistance. Some tight time frames necessitate delegating 90% of the tasks to outside resources, while other, more leisurely projects, may require only 10% assistance levels.

A key distinction to make at this point is between the design resources and the deployment resources. The company or individuals in charge of the design work must have significant experience with the technologies to be implemented and be able to educate and lead the other members of the project team. For projects of moderate or greater complexity, these resources should be dedicated to the design process to ensure that the details are fully sketched out, and the solution designed is as well thought out as possible. Often the design team has the challenging task of negotiating with the key stakeholders concerning the final design, because not all the staff will get everything they want and wish for in the project. The deployment team may contain members of the design team, and these individuals should have training and hands-on experience with the technologies involved and will have more end user interaction.

There are certain prerequisites to look for when choosing an independent consultant or solution provider organization as a partner. Without going into too much detail, the individual or firm should have proven experience with the exact technologies to be implemented, have a flexible approach to implementing the solution, and have specialized resources to handle the different components of the project. No one person can “do it all,” especially if he gets sick or goes on vacation, so breadth and depth of experience should be considered. Obviously, the hourly fees charged are important, but the overall costs, if a firm is willing to commit to a cap or not to exceed price, can be more important. In the current business environment, it makes sense to invest your time wisely in choosing a firm that is very good at what it does, or it might not be around in future months when your project reaches its critical phases.

Soft skills of the partner are also important because many projects are judged not only by whether the project is complete on time, on scope, and on budget, but also by the response of the stakeholders and user community. Communications skills, reliability, and willingness to educate and share knowledge along the way bring great value in the long run.

At the same time that data is being gathered and verified pertaining to what is in place and what it does, connectivity between devices should also be reviewed, to review the logical components of the network as well as the physical. This information may be available from existing diagrams and documentation, or may need to be gathered in the field.

Important items to understand include: How are DNS, WINS, and DHCP being handled? Are there VPNs or VLANs in place? How are the routers configured? What protocols are in use? What types of circuits connect the offices: T1, fractional T1s, T3, ATM? What are the guaranteed throughputs or CIRs in place?

Has connectivity failure been planned for through a partially or fully meshed environment? Connections to the outside world and other organizations need to be reviewed and fully understood at the same level, especially with an eye toward the security features in place. The best security design in the world can be defeated by a modem plugged in a plain old telephone line and a disgruntled ex-employee.

Along the same lines, remote access needs, such as access to email, network file and print resources, and the support needs for PDAs and other portable devices, should be reviewed.

Geographically diverse companies bring added challenges to the table. As much as possible, the same level of information should be gathered on all the sites that will be involved in and affected by the migration. Is the IT environment centralized, where one location manages the whole environment, or decentralized, where each office is its own “fiefdom”?

The distribution of personnel should be reviewed and clarified. How many support personnel are in each location, what key hardware and software are they tasked with supporting, and how many end users? Often different offices have specific functions that require a different combination of support personnel. Some smaller remote offices may have no dedicated staff at all, and this may make it difficult to gather updated information. Accordingly, is there expansion or contraction likely in the near future or office consolidations that will change the user distribution?

Problems and challenges that the WAN design has presented in the past should be reviewed. How is directory information replicated between sites, and what domain design is in place? If the company already has Active Directory in place, is a single domain with a simple organizational unit (OU) structure in place, or are there multiple domains with a complex OU structure? Global catalog placement should also be clarified.

How is the Internet accessed? Does each office have its own Internet connection, firewall, router, and so on, or is access through one location?

The answers to these questions will directly shape the design of the solution, as well as affect the testing and rollout processes.

Another area that can dramatically affect the design of the Windows Server 2003 solution to be implemented is the place where the company’s data lives and how it is managed.

At this point, you should know what the key network software applications are, so it is worth having some numbers on the amount of data being managed and where it lives on the network (one server? ten servers?). The total number of individual user files should be reviewed, and if available, statistics on the growth of this data should be reviewed.

Database information is often critical to an organization, whether it pertains to the services and products the company offers to the outside world, or enables the employees to perform their jobs. Databases also require regular maintenance to avoid corruption and optimize performance, so it is useful to know whether maintenance is happening on a regular basis.

Mail databases pose their own challenges. Older mail systems typically were quite limited in the size of their databases, and many organizations were forced to come up with interesting ways of handling large amounts of data. As email has grown in importance and become a primary tool for many companies, the in-box and personal folders have become the primary storage place for many email users. If the organization uses Microsoft Exchange for its email system, users may have personal stores and/or offline stores that may need to be taken into account.

How the data is backed up and stored should also be reviewed. Some organizations have extremely complex enterprise storage systems and use clustering, storage area networks, and/or a distributed file system to ensure that data is always available to the user community. Sometimes hierarchical storage processes are in place to move old data to optical media or even to tape.

An overall goal of this sleuthing is to determine where the data is, what file stores and databases are out there, how the data is maintained, and whether it is safe. It may also become clear that the data can be consolidated, or needs to be better protected through clustering or RAID solutions. The costs to the company of data loss or temporary unavailability should also be discussed.

The design team is most likely not ready to make all the decisions yet, even though quite a bit of homework has already been done. A more formal collaborative and educational process should follow to ensure that the end state of the project is defined in detail and that the design team members fully understand the new technologies to be introduced.

The collaborative process involves interactive brainstorming and knowledge-sharing sessions, in which the stakeholders work with facilitators who have expertise with the technologies in question.

Ideally, a consultant with hands-on experience designing and implementing Windows Server 2003 will provide leadership through this process. Well-thought-out agendas can lead the design team through a logical process that educates them about the key decisions to be made and helps with the decisions.

Whiteboards can be used to illustrate the new physical layout of the Windows Server 2003 environment, as well as to explain how the data will be managed and protected on the network. Notes should be taken on the decisions that are made in these sessions. If the sessions are effectively planned and executed, a relatively small number of collaboration sessions will provide the key decisions required for the implementation.

With effective leadership, these sessions can also help establish positive team dynamics and excitement for the project itself. Employees may feel negative about a major upgrade for a wide variety of reasons, but through contributing to the design, learning about the technologies to be implemented, and better understanding their own roles in the process, attitudes can change.

Through these sessions, the details of the end state should become crystal clear. Specifics can be discussed, such as how many servers are needed in which locations, which specific functions they will perform (file and print or application servers, firewalls, and so on), and which key software applications will be managed. Other design decisions and logistical concerns will come up and should be discussed, such as whether to use existing server and network infrastructure hardware or to buy new equipment. Decisions also need to be made concerning secondary applications to support the upgraded environment, such as tape backup software, antivirus solutions, firewall protection, and network management software.

Ideally, some of the details of the actual migration process will start to become clear. For instance, the members of the testing and deployment teams, the training they will require, and the level of involvement from outside resources can be discussed.

The complexity of the project will affect the size of the document and the effort required to create it. As mentioned previously, this document summarizes the goals and objectives that were gathered in the initial discovery phase and describes how the project’s result will meet them. It should represent a detailed picture of the end state when the new technologies and devices have been implemented. The amount of detail can vary, but it should include key design decisions made in the discovery process and collaboration sessions.

The following is a sample table of contents and brief description of the design document:

As the previous section mentioned, the key Windows Server 2003 design decisions should be recorded in the design document. This is perhaps the most important section of the document because it will define how Windows Server 2003 will be configured and how it will interact with the network infrastructure.

Decisions should have been made about the hardware and software needed for the migration. They should take into account whether the existing hardware will be used in the migration, upgraded, left in place, or retired. This decision, in turn, will determine how many server software licenses will be required, which will directly affect the costs of the project.

The level of redundancy and security the solution will provide should be detailed. Again, it is important to be specific when talking about data availability and discussing the situations that have been planned for in the design.

The server and other infrastructure hardware and software should be defined in this section. If upgrades are needed for existing hardware (more processors, RAM, hard drives, tape drives, and so on) or the existing software (upgrades from the existing NOS, server applications, and vertical market applications), they should be detailed here.

Other key technologies such as messaging applications or industry-specific applications will be included here, in as much detail as appropriate.

The final step in the design document process actually takes place after the document has been created. When the document is considered complete, it should be presented to the project stakeholders and reviewed to make sure that it does, in fact, meet their requirements, that they understand the contents, and to see whether any additional concerns come up that weren’t addressed in the document.

Although it is unlikely that every goal of every stakeholder will be met (because some may conflict), this process will clarify which goals are the most important and can be met by the technologies to be implemented.

Specific decisions made in the design document that should be reviewed include any disparities between the wish lists the stakeholders had and what the final results of the project will be. Also, the timeline and high-level budget should be discussed and confirmed. If the design document outlines a budget of $500K for hardware and software, but the stakeholders won’t be able to allocate more than $250K, the changes should be made at this point, rather than after the migration document is created. A smaller budget may require drastic changes to the design document because capabilities in the solution may need to be removed, which will have ripple effects throughout the project.

If the time frame outlined in the design document needs to be modified to meet the requirements of the stakeholders, this should be identified prior to expending the effort of creating the detailed implementation plan as well.

Bear in mind as well that the design document can be used for different purposes. Some companies want the design document to serve as an educational document to inform not only what the end state will look like, but why it should be that way. Others simply need to document the decisions made and come up with budgetary information.

Having this level of detail will also make it easier to get competitive bids on the costs to implement. Many organizations make the mistake of seeking bids for solutions before they even know what the solution will consist of.

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, like those shown in Figure 2.1, 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.

Figure 2.1. High-level migration project plan.

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 may be encountered. Each phase of the project needs to be outlined and then expanded, similar to the sample prototype testing phase plan shown in Figure 2.2.

Figure 2.2. Sample Windows Server 2003 prototype testing phase project plan.

Note that in the example in Figure 2.2, the tasks are kept on a high level, but additional details can be included as needed. 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.

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 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 cost changes. 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 20 hours of work in a 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 may well be another. Administrative and end-user training may need to happen to ensure that the resulting environment can be effectively supported.

You may 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 where customization of the NOS is required or directory information needs to be modified.

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.

The following is a sample table of contents and brief description of the migration document:

Although the details of the project will determine the specifics of exactly what will be in the prototype lab, certain common elements will be required. The migration document should clearly outline the components of the lab and what applications and processes should be tested. A typical environment will consist of the primary Windows Server 2003 required for the implementation, as well as network switches, sample workstations, and printers from the production environment. Connectivity to the outside world should be available for testing purposes.

A key decision to make is whether the lab will be implemented into the environment or stay as a lab. Some companies will proceed from the prototype phase to the pilot phase with the same equipment, whereas others prefer to keep a lab set up for future use. The advantages of having a lab environment for a Windows Server 2003 environment are many, and include testing NOS and application updates, upgrades and patches, as well as having hardware available for replacement of failed components in the production environment.

Real data and applications should be installed and tested. Data can be copied from live production servers, or data from tape can be restored to the test server. Applications should be installed on the servers according to a manufacturer’s installation instructions; however, compatibility validation with Windows Server 2003 should be conducted as outlined in Chapter 18, “Compatibility Testing for Windows Server 2003.”

After the software applications have been installed, representative users from the different company departments could be brought into the lab to put the applications through their paces. These users will be best able to do what they normally do in the lab environment to ensure that their requirements will be met by the new configuration. Areas that don’t meet their expectations should be recorded and identified as either “show stoppers” that need to be addressed immediately or issues that won’t harm the implementation plan.

A number of things come out of the lab testing process, besides the valuable learning that takes place. If time permits, and there is room in the budget, a variety of documents can be produced to facilitate the pilot and implementation process. Another key result of the lab is hard evidence of the accuracy and completeness of the design and migration documents.

Some of the documents that can be created will assist the deployment team during the migration process. One key document is the “As Built” document, which provides a snapshot of the key configuration details of the primary servers that have been configured and tested. Whereas the design document outlines many of the key configuration details, the “As Built” document contains actual screenshots of the server configurations as well as the output from the Windows Server 2003 Computer Management administrative tool that provides important details such as physical and logical disk configuration, system memory and processor information, services installed and in use on the system, and the like.

Another important document is the disaster recovery document (or DR document). This document should outline exactly which types of failures were tested, and the process for rectifying these situations. Keep in mind that a complete disaster recovery plan should include offsite data and application access, so the DR document that comes out of the prototype phase will in most cases be more of a hardware failure document that discusses how to replace failed components such as hard drives or power supplies, and how to restore the server configuration from tape backup or restore data sets.

If you need to implement multiple servers in the pilot and implementation phases, you can document checklists for the step-by-step processes in the prototype phase. Bear in mind that creating step-by-step documents takes a great deal of time (and paper!), and a change in process requires drastic changes to these documents. Typically, creating a step-by-step “recipe” for server builds is not worth the time unless lower-level resources need to build a large number in a short period of time.

When the testing is complete, the migration plan should be revisited to make sure that the timeline and milestones are still accurate. Ideally, there should be no major surprises during the prototype phase, but adjustments may be needed to the migration plan to ensure the success of the project.

Depending on the time frame for the pilot and implementation phases, the hardware and software that will be needed for the full implementation might be ordered at this point. As the cost of server hardware has decreased over the past several years, many companies “over-spec” the hardware they think they need, and they may determine during the prototype phase that lesser amounts of RAM or fewer processors will still exceed the needs of the technologies to be implemented, so the hardware requirements may change.

The pilot phase is begun when the first Windows Server 2003 accessed by users is implemented in the production environment. Dependent on the scope of the migration project, this first server may be a simple application server running Terminal Services or SharePoint Team Services, or the first server may be the root of the Active Directory tree.

Just as in the prototype phase, the testing to be conducted in the pilot phase is to verify successful access to the server or application services the system provides. One of the best ways to validate functionality is to take the test sequences used in the prototype phase and repeat the test steps in the pilot production environment.

The major difference between the prototype and pilot phases is interconnectivity and enterprisewide compatibility. In many lab-based prototype phases, the testing is isolated to clean system configurations or homogeneous system configurations; however, in a pilot production environment, the new technology is integrated with old technology. It is the validation that the new setup works with existing users, servers, and systems, and software is the added focus of the production pilot phase.

The pilot phase is usually rolled out in sub-phases, with each sub-phase growing in number of users affected, uses of system technology by the pilot users, and the distribution of users throughout the organization.

No matter how much planning and testing are conducted in the earlier phases of the project, problems always crop up in the pilot phase of the project. It is important to have the prototype lab still intact so that any outstanding problems can be re-created in the lab, tested, and resolved to be tested in the pilot production phase again.

After the pilot, it is important to document the results. Even with the extensive discovery and design work, as well as the prototype lab testing and pilot phases that have taken place, problems may reoccur in the post-pilot phases, and any documented information on how problems were resolved or configurations made to resolve problems in the pilot phase will help simplify the resolution in future phases. If you take some extra time to give attention to the pilot users, you can fine-tune the solution to make sure the full implementation is a success.

A critical task that can be conducted at this point in the project is to conduct a checkpoint for end user satisfaction, making sure that users are getting their systems, applications, or functionality upgraded; questions are answered; problems are resolved; and most importantly, users are being made aware of the benefits and improvements of the new environment.

Not only does this phase of the project focus on the rollout of the technology, but it is also the key public relations and communications phase of the project. Make sure the user community gets the training and support it needs throughout the process. Plan on issues arising that will need support for several days after each department or user group is upgraded. Don’t forget the special users with unique requirements and remote users because they will require additional support.

Before the last users are rolled into the new networking environment, besides planning the project completion party, you need to allocate time to ensure the ongoing support and maintenance of the new environment is being conducted. This step not only includes doing regular backups of the new servers (covered in detail in Chapter 32, “Backing Up a Windows Server 2003 Environment”), but also includes planning for regular maintenance (Chapter 22, “Windows Server 2003 Management and Maintenance Practices”), monitoring (Chapter 25, “Integrating Microsoft Operations Manager with Windows Server 2003”), and tuning and optimization (Chapter 35, “Capacity Analysis and Performance Optimization”) of the new Windows Server 2003 environment.

Now is the time to begin planning for some of the wish list items that didn’t make sense to include in the initial migration—for example, a new antiviral solution, knowledge-management solutions, enhanced security, and so on. If you have a lab still in place, use it for testing patches and software updates.