Understanding the Migration Process

By Megan Davis, MCSE, Web Technologies Writer,Internet Information Services Documentation Team,Microsoft Corporation

This article is the first in a series that discusses steps you can take to get ready for Internet Information Services (IIS) 5.0 when it becomes available later this year. This article provides a high-level overview of all the steps involved in a Web services migration project that involves multiple Web servers in an enterprise environment. Understanding the process will help you plan for the work involved. Planning will be described in greater detail in the next article in this series.

Using the Microsoft Solutions Framework

The best way to think about the migration process is in terms of the Microsoft Solutions Framework (MSF) model for Infrastructure Deployment, developed by Microsoft to assist customers in deploying business solutions. MSF is a flexible, interrelated series of models that can guide an organization through assembling the resources, people, and techniques needed to bring technology infrastructure in line with business objectives. You can use MSF together with your own tools and techniques to plan and manage a migration project. For more information about MSF, see:

https://www.microsoft.com/technet/itsolutions/msf/default.mspx

The following graphic depicts the MSF process model, consisting of envisioning, planning, developing, and deploying, along with related milestones.

The MSF Model for Infrastructure Deployment

The following table lists the activities that are involved in each phase of a migration project in terms of the MSF phases and milestones:

Envisioning

Main Task: Creating the Vision and Scope Document

During the Envisioning phase, the project team creates a Vision and Scope document to define the following:

• Project goals, scope, constraints, and assumptions.

• Project requirements.

• Conceptual design for services.

• High-level project risks.

• Structure of the project team.

The Envisioning phase focuses the team on creating solid business value. It keeps your organization from investing significant effort on minor needs or from improving bad processes rather than creating good ones. The best results are based on open thinking about how the proposed solution may address not only the most visible current need, but also the underlying causes of that need.

1.A. Define the Project

The first section of the Vision and Scope document should provide clear direction to the team by defining project goals, scope, constraints, and assumptions. Asking questions such as the following will help you in this effort:

• Vision What final outcome or result do we envision for the project, at a high level? For example, a vision statement might be, "To leverage information technology through fast and cost-effective development and deployment of crucial line-of-business applications." A vision statement can also include a conceptual design drawing, as described later.

• Scope What functionality can we reasonably implement during this project, and what should be postponed to a later date? Project variables-resources (people and money), schedule (time), and features (the solution)-exist in a triangular relationship, as depicted in the following diagram. Setting project scope requires balancing these variables. This is accomplished by trading desired, but inessential, features for a shortened project schedule or reduced resource requirements, for example.

  

• Assumptions What assumptions are implicit in the project plan? Some assumptions might include that a valid Windows 2000 Server domain design has been implemented, or that qualified staff is available.

1.B. Create a Requirements Definition

It's important to clearly define the requirements for the new Web service in your Vision and Scope document. Your primary reason for migrating to IIS 5.0 could be as simple as adding Web services to your corporate network or as far-reaching as automating workflow processes or providing online transaction processing. You might also have a number of secondary goals. Although you might not have the resources to realize every goal at this time, it is worthwhile to list the more important ones to include in longer-range planning.

1.C. Develop a Conceptual Design

From the requirements definition you can develop a conceptual design that reflects your goals and requirements and takes into account the current network and server environment. This is usually a high-level drawing included in your Vision and Scope document that depicts an optimal solution. The following figure is an example of a conceptual design.

This figure shows a corporate system that includes an intranet and a corporate Internet Web site. It supports internal and Internet e-mail through Microsoft® Exchange Server. Sensitive company information and the company intranet is secured from outside intrusion by a firewall.

1.D. Assess Risk

Migrating a Web server can involve some risk. Analyzing risks before you begin a project, and implementing methods to mitigate them, can reduce any undesirable impact on your business. The following table lists some high-level project risks and mitigation strategies. You should include this type of assessment in your Vision and Scope document. Your list will probably include some risks that are more specific to the parameters of your project. A downloadable "Risk Assessment Form," which you can use for evaluating risks for your project, will be provided with the next article in this series, "Planning a Migration Project."

1.E. Define the Project Team

In the MSF model, a project is planned and implemented by a team of peers. Each member is responsible for a functional area of the project, but overall project responsibility rests with the team as a whole. The project team definition of the Vision and Scope document identifies functional areas to be addressed by team members and assigns individual roles and responsibilities. For a small project, a single team member can be responsible for one or more functional areas. On larger projects, a separate team might be assigned to each functional area.

Main Milestone: Vision and Scope Approved

The main milestone for this phase is approval by the project team of the Vision and Scope document. Creating this document will be discussed in the next article in this series, "Planning a Migration Project." A document template will also be included.

Planning

Main Task: Creating the Master Project Plan and Schedule

Planning, the second phase of the MSF process model, is one of the most important activities in a migration project. Careful planning can make the difference between a smooth transition to IIS 5.0 and a rocky one. During this phase, the project team defines the following:

• What solution the project team will deliver. The solution is defined in a functional specification document.

• How the solution will be developed, tested, and deployed, in the form of a master project plan.

• When development of the solution will begin and when its deployment will be completed, in the form of a project schedule.

As part of this process you will gather information about current services, define the new service offering, and assess resource needs and time requirements for carrying out the project. These activities will yield the information you need to build the functional specification, the master project plan, and the schedule.

These activities will be discussed in detail in the next article in this series, "Planning a Migration Project." Downloadable templates and forms to assist you in the process of gathering information and compiling it into plans will be provided.

Team Roles During the Planning Phase

During the previous phase, Envisioning, product management had a focal role. Now team focus shifts to the program management, where it will remain during the Planning and Developing phases.

To see a description of the roles and responsibilities typically necessary in a migration project, see the Team Roles During the Planning Phase table.

Main Milestone: Project Plan Approved

The milestone for this phase is approval by the project team of the Master Project Plan and Project Schedule.

Developing

Main Task: Developing, Testing, and Building Out the System

An approved functional specification and associated project plan provides the baseline for focused development to begin. During the Developing phase, the development team creates and validates the detailed design through testing and debugging. The system is built, training of administrators and key users begins, and, finally, pilot testing is conducted.

3.A. Validate the Design

During the planning phase, the team created a detailed system design. When complete, you're ready to validate it. Validating the design consists of performing unit, integration, and application testing to ensure the proposed system functions as expected and required. This testing is usually conducted in a lab environment, which will be described in greater detail in the next article in this series, "Planning a Migration Project."

Testing can be divided into four basic categories:

• Unit Testing Performed in the unit test lab, unit testing validates functionality of the Web server independent of other computers and systems.

• Integration Testing Performed in the integration test lab, integration testing ensures functionality, performance, and security of the Web server in the context of a network, and the platforms and servers with which the server will operate.

• Application Testing To verify Web application functionality and performance, application testing progresses from a development computer for basic functionality testing, to the unit lab, and finally to the integration lab to test its functionality in context.

• Pilot Testing Conducted by typical system users, usually on their own workstations, pilot testing demonstrates the usability of the Web services.

The testing process is iterative rather than linear. For example, you may discover a problem during an integration test, correct it and test the solution, and then go back to unit testing to find out if the correction has changed your results. In addition, it's frequently possible to conduct two or more procedures concurrently in order to complete testing at an earlier date.

3.B. Build out the System

Once the detailed design has been tested and validated, you're ready to build the system, configuring and locating the production Web servers that will be used on your network. When the Release milestone for the Developing phase has been achieved, you will be ready to deploy the new servers, as described later.

3.C. Begin Training

As soon as possible, begin training administrative staff, support personnel, and key users. Any staff members who will be working with IIS 5.0 during or after the migration will benefit from taking a Microsoft-certified course in IIS 5.0. In addition to training the individuals who will be performing the migration and administering servers, you'll probably want to provide end-user training and support as well. In addition, Web developers will benefit from training on subjects such as creating ASP-based applications and using Microsoft FrontPage to publish Web pages.

For more information about available Microsoft training, see: https://www.microsoft.com/learning/default.asp

For information about other books and training materials on Microsoft products, see: https://www.microsoft.com/mspress/

3.D. Conduct Pilot Testing

Pilot testing involves having a group of end users try the system prior to its full deployment in order to give feedback on IIS 5.0 features and functions. The level of pilot testing you want to perform depends on the size and scope of your migration project. For larger projects, a formal, carefully planned pilot is essential. For any size project, it's a good idea to have selected end users test the system prior to full deployment.

During the initial, pre-pilot phase you can select a small group of technically savvy users to try out the technology. You probably won't want to provide support during this phase because it can draw resources away from system development and burden your schedule.

After making adjustments based on input from the pre-pilot users, you can begin the actual pilot. During this phase a larger group of users should review and fully use system features. These users should be at about the same technical level as your system users in general. During this phase, you should plan to provide support for all issues, errors, or problems that users report. When you make any corrections, be sure to thoroughly retest the system.

Team Roles during the Developing Phase

During this phase, program management continues to take the lead. To see a description of team roles and responsibilities during this phase, go to Team Roles during the Developing Phase table.

Main Milestone: Release

The main milestone for the Developing phase is Release. At the Release milestone, the team assesses product functionality and verifies that rollout and support plans are in place. All new development is complete, and deferred functionality is documented for the next release.

Deploying

Main Task: Making the New Services Available to End Users

The final phase of the migration process, in the MSF model, is Deploying. During this phase, the team must transition from creating elegant development solutions to complying with the rigid operational requirements of thorough and complete testing. The goal of this phase is making the new services available to the target audience and users. This requires completing user and administrator training, rolling out and monitoring the system, and bug fixing.

4.A. Finish Training

Prior to rolling out the new system, you need to ensure that all system administrators, support staff, and users have completed training. In addition, user support systems should be in place.

4.B. Roll out the New System

You're ready to make the new system available to all prospective users, when you've completed the set of tasks listed on this checklist. At this point, you're ready to make the new IIS 5.0 server available to users on the network. For a large-scale migration, or one involving mission-critical applications, you might deploy the server in steps, making its services available to progressively larger groups of users over time.

There are several technical approaches to taking a production server out of service and bringing the new server on your network to begin hosting. The method you choose should be based on your network policies, amount of acceptable downtime, and your technical knowledge. Here are two possible methods:

• If some downtime is acceptable, turn off the existing production server and simultaneously start the new IIS 5.0 server using the IP address and network settings of the existing production server. You might experience several minutes of server downtime; however, problems should be minimized if you perform the switch during off-peak hours and inform users several days in advance.

• If no downtime is acceptable assign the new IIS 5.0 server a new IP address, and set the transistor-transistor logic (TTL) units in the domain name system (DNS) records to expire in 24 hours. Set up round-robin DNS so requests are sent sequentially to the production server and the new IIS 5.0 server. Wait for the DNS to propagate. After the first propagation, turn off the round-robin setting on the production server, and wait for propagation to occur again. When you're sure the new IP has been propagated, turn off the production server. However, use caution if you're using tracking or dynamic capabilities on your site, as problems could occur.

Of course, if you're using a server clustering tool such as Microsoft® Windows® Load Balancing Service, all you need do is assign the new server the appropriate IP address and bring it onto the network, then take the old production server offline.

4.C. Monitor the System

It's important to monitor the performance of the new IIS 5.0 server, especially in the first few days after deployment to ensure your users are not encountering problems when visiting your Web sites. During this time you'll also want to fine-tune server performance. Use Microsoft® Windows® 2000 Server Performance Monitor or HTTPMon, which will be included on the Windows 2000 Resource Kit companion CD, to track server performance. Performance degradation can alert you to a serious problem. Some suggested items to monitor are processor use, memory use, disk use, and network availability.

No matter how carefully you've planned and carried out the migration, you're bound to run into a glitch or two following system deployment. There are a number of resources to help you troubleshoot problems that occur with the new IIS 5.0 server. For example, by participating in a related newsgroup you can get troubleshooting information from other IIS 5.0 users, such as the newsgroup sponsored by 15seconds.com. In addition, Microsoft provides searchable reference information that may be of help at: https://support.microsoft.com/support/

For debugging applications, try using the search string "application debugging."

Team Roles during the Deploying Phase

During this phase, a subtle shift occurs in the dynamics of the project team. Here, the logistics manager will step to center stage. The logistics manager will often share the focus of the project with user education as the systems are actively deployed, users receive the appropriate training, and the operations and support systems are activated.

To see a description of team roles and responsibilities during this phase, see the Team Roles during the Deploying Phase table.

Main Milestone: Deployment Complete

The milestone for this phase is Deployment Complete, when the system can be formally turned over to operations and support for maintenance.

Getting Project Assistance

Every migration project varies in size, scope, and objectives. While this article has given you an overview of the basic tasks involved, you may require additional assistance, especially when planning and managing a large-scale migration involving multiple geographic locations and numerous servers and users. If so, you might want to consider contacting a Microsoft Solution Provider or a Microsoft Consultant. For more information about obtaining this help, see:

https://www.microsoft.com/technet/itsolutions/msf/default.mspx

For help with planning and deploying Microsoft® Windows® 2000 Server solutions, see:

https://www.microsoft.com/windowsserver2003/default.mspx