04/03/2018 Chapter 6 - Deploying Phase

Chapter 6 - Deploying Phase

On This Page
Goals for the Deploying Phase
Team Focus during the Deploying Phase
Completing Deployment Preparations
Creating Operations Procedures
Deploying the Solution
Stabilizing the Deployment
Transferring Ownership to Operations
Project Review
Closing the Deploying Phase
Key Milestone: Deployment Complete

Goals for the Deploying Phase

Figure 6.1: The Deploying Phase of the MSF Process Model

The overarching goal of the Deploying Phase is to place the solution into a production environment. Supporting goals
include deploying the solution technology and components, stabilizing the deployment, and transitioning the project to
operations and support. After the deployment, the team conducts a project review and a customer satisfaction survey.
Stabilizing activities may continue during this period. The Deploying Phase culminates in the Deployment Complete
Milestone, when the team obtains final customer approval of the project.

The tasks summarized in Table 6.1 need to be completed during the Deploying Phase. This project guide describes the
processes and roles required to accomplish them. Detailed information specific to each migration project about each task,
especially technical information, is provided in the migration guide for that project.

Table 6.1 Major Deploying Phase Tasks and Owners

Major Tasks Owners

Completing deployment preparations Release Management,

The team updates the deployment plan installs, configures, and tests hardware and software Development
components.

Creating operations procedures Release Management,

The team creates and documents procedures and defines checkpoints to help the operations Development
team monitor and maintain the solution.

Deploying the solution Release Management,

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 1/16
04/03/2018 Chapter 6 - Deploying Phase

The team deploys the core technology and completes site deployments. Development

Stabilizing the deployment Project Team

Project team and operations work toward a predefined state of completion for the solution.

Transferring ownership to operations Release Management

The team formally hands over responsibility for the solution to the operations team.

Closing the Deploying Phase Project Team

The team meets the Deployment Complete Milestone requirements and later completes post-
project reviews with the customer and project team.

Top of page
Team Focus during the Deploying Phase
Table 6.2 addresses the tasks described previously, but considers them from the perspective of the team roles.

The primary team role driving the Deploying Phase is Release Management.

Table 6.2 Role Cluster Focuses and Responsibilities in Deploying Phase

Role Cluster Focus and Responsibility

Product Management Customer feedback, assessment, and sign-off

Program Management Solution/scope comparison; stabilization management

Development Problem resolution; escalation support

User Experience Training; training schedule management

Test Performance testing; problem identification, definition, resolution, and reporting

Release Management Site deployment management; change approval

Top of page
Completing Deployment Preparations
This section describes MSF recommendations for deployment and the operational procedures that a project team can use to
quickly and successfully complete a UNIX migration deployment and then transfer responsibility to operations.

The project team can deploy the solution upon completion of the Stabilizing Phase in a variety of ways. One option is to use
the organizations operations team to handle the actual deployment. If the operations team manages the entire deployment,
representatives from the development team usually remain on the project for a period of time after going live to mitigate
potential problems during the solutions transfer of ownership. A second option is to combine members from each group and
create a separate deployment team. The Release Management Role is responsible for coordinating the required activities
that ensure a successful deployment.

Deployment Procedures
During development, and especially as the Stabilizing Phase nears completion, the Release Management lead assigns
deployment tasks to the staff. These individuals review the project status and test results and update the deployment plan,
which was initially created during the Planning Phase. The team creates task-based procedures that help ensure a successful
deployment. During each of the previous phases, the team gathered information that identified what tasks need to be

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 2/16
04/03/2018 Chapter 6 - Deploying Phase

completed before transferring the solution. The tasks summarized in the following section reiterate significant completion
points.

Staging and Production Environments

To prepare for deployment, the physical infrastructure, system software, and application software are tested, installed, and
configured within their respective environments.

Physical Infrastructure

During the Planning Phase, the project team resolved the projects conceptual, logical, and physical architecture by
considering the metrics of scale. The project team determined how it would configure the solution architecture,
including the amount and specific types of hardware and software needed, how the software would be installed and
configured on each computer, and what other components would be required to deploy and maintain the solution.
For infrastructure migrations, the actual new physical and service hardware was completely built and tested, as that
was the primary goal of the project.

System Software

The project team updates documentation of all commercial software (operating system, database platform,
networking protocols, and so on) used for the solution and installs the software on each environments servers.

Application Software

The project team installs all commercial software applications required to support the environment including desktop
tools such as spreadsheets or word processors.

Consult the vendor's various testing scenarios to verify and validate that the hardware and software are installed and
configured correctly and there are no issues within each of the environments.

Custom Application Software (created or modified by the migration development team)

The project team finalizes documentation of all application software created by the development team for the
solution and installs the custom application software on the environments servers. The testing conducted on custom
applications should comply with the design and test requirements for each application.

Documentation

The project team and operations representatives will revisit and update the following documentation, ensuring it is ready for
transfer to operations:

Deployment diagrams

Event-sequence charts from actual observations

Test plan including coverage for areas exposed in real use

Reliability plan

Security plan

Backup plan to prevent loss of data

Plan for analyzing system performance and solution usage

Plan for log handling and other administrative tasks

Disaster recovery plan

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 3/16
04/03/2018 Chapter 6 - Deploying Phase

Business contingency plan

Training information

Customer Sign-off

The solutions key stakeholders review the collateral and solution and confirm it is ready for deployment. The project team
prepares an affidavit reiterating that the key stakeholders have reviewed the solution and the accompanying collateral, and
that they find the solution to be final and acceptable as it is.

Top of page
Creating Operations Procedures
The operations team is responsible for many duties and tasks once it receives ownership of the solution. To facilitate the
transition and help this team assume its assigned tasks, MSF recommends creating and documenting procedures and
defining a series of checkpoints at this time.

Team Objectives
As mentioned previously, the operations team is represented on the project team throughout the project through the
Release Management Role. As the Stabilizing Phase nears completion, the teams begin to transition into a deployment team.
The operations team retains certain members of the development team to assist with deployment and stabilization, while
other members will begin to disengage from the project. The deployment team also might recruit members from outside the
projects environment.

Once the solution is successfully deployed, the operations team is responsible for maintaining the solution on a continual
basis. This allows the team to proactively deal with problems. The team performs all daily maintenance procedures and
provides low-level routine change management for the solution. Any large-scale changes are the responsibility of the
Product Management Role or marketing function.

Team Roles and Responsibilities

The following personnel are involved in managing the successfully deployed solution:

Operations and support personnel routinely maintain and monitor the solution for low-level changes and ensure
operation according to the defined operational requirements.

The administrative staff monitors capacity changes and collects user profiles.

The marketing staff analyzes the use and success of the solution in terms of the original plan, vision, and new add-ins.
Marketing is also responsible for gathering and prioritizing change requirements to the solution overall.

Project Validation
Upon receipt of the solution ownership, the operations team immediately validates all collateral and equipment included in
the transfer. This should proceed quickly because operations was represented throughout the project. The operations team
validates the systems environment, equipment, software, configurations, and the following plans:

The disaster recovery plan

During the Planning Phase, the team created a disaster recovery plan establishing what the team expects to happen
to the solution, its equipment, personnel, and data should a crisis occur. At this time, the team reviews the document
and validates and updates its contents.

The plan might include the list of personnel who are supporting each of the components and specify who takes
responsibility to notify management and staff when a crisis occurs, where the team will reconvene after a disaster
strikes, and what actions should be taken to close the system down prior to evacuating the premises.

Disaster recovery plans should also include information for less catastrophic events. Good disaster recovery plans
should also include:

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 4/16
04/03/2018 Chapter 6 - Deploying Phase

Identification of all known potential failure modes.

Documented recovery processes for each of these modes.

Documented testing results illustrating test procedures that successfully forced the failure modes and
verification that the recovery processes resulted in system recovery.

Documentation and training information, as well as backup tapes or archived files, must be stored off site.

The team also must ensure the training of support personnel who would be involved with maintaining or updating the
solution, and ensure that proper channels or regulations are met in the event of a disaster.

The business contingency plan

During the Planning Phase, the team created a business contingency plan, establishing what will happen should
business activities halt. At this time, the operations team reviews and validates the contents of the business
contingency plan. If necessary, the team provides updated information on team members and other pertinent
information to the plan.

The security procedures

During the Planning Phase, the team created a security plan. At this time, the operations team upgrades and confirms
that all security procedures are in place. The team should ensure that all permissible personnel are aware of the
security standards and rules to which this project adheres.

Procedural Checklist
The operations team is responsible for the solutions daily maintenance and routine care. The team should create a checklist
to ensure that it is proactive when maintaining the system and that any potential issues are avoided as much as possible.
Operation teams may want to include the following questions on the checklist:

Have the service packs, drivers, or new versions of hardware and software been rigorously tested? Is there a procedure
set up to alert the team should these items fail?

Is the solutions capacity monitored on a daily basis? Is there an alert if additional equipment is required? What is the
procedure to obtain new equipment?

How are critical diagnostic messages identified? What will the team do to provide immediate relief to the critical error
messages?

What will the team do if something fails? Will the team use third-party tools to identify and correct these issues?

How will the operations team validate data integrity on a daily basis? How will the team make sure nothing is corrupt
because of memory or program failures?

How will the team monitor the solutions components? If a component fails, how will the team rectify the problem?

What process will the team use for file and data backups?

What process will the team use for content changes?

What processes will the team use to ensure the system is providing the functionality that was intended, per the
specifications?

Top of page
Deploying the Solution
Because deployment into the production environment can be complex, a transition process provides a quality assessment to
ensure that all elements are ready. Checklists and procedures are invaluable tools during this stage.

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 5/16
04/03/2018 Chapter 6 - Deploying Phase

Transitioning to Deployment
As they learn new information, project team members continually update and revise the deployment plan during the
developing and stabilization phases while testing the solution. This approach minimizes schedule delays caused by last-
minute changes. The Release Manager must review and revise the deployment plan and confirm that the team has
accomplished the following tasks:

The deployment strategy is reviewed and approved.

Setup, installation, configuration, test, operation, and support procedures are available, reviewed, and approved.

Deployment procedures are documented, reviewed, and approved.

Hardware and software components are available and tested.

The deployment team has clearly defined roles, and the assigned personnel are trained and available.

The project schedule has been reviewed and approved.

There is a plan and ample resources for ownership transfer to the operations team.

While both testing and production pilots are excellent practices, neither can completely reproduce the actual solution usage
and performance experience after going into the live production environment. The amount of work and the increased level
of activity that typically occurs in the weeks prior to deployment could lead to some issues being overlooked. It is vital that
the project team continues to monitor the solution after deployment until the transfer of ownership is finalized. This allows
the team to establish baseline performance records to determine whether performance is improving or deteriorating. If the
stress and capacity tests are executed well, the team should have both test scripts and test results available that provide the
baseline numbers.

It is important to compare the baseline numbers to the new numbers any time a change is made to the solution, including
infrastructure and code components. It is best if the team makes one change at a time; otherwise, it is difficult to tell which
change produced which effect. If performance does not improve as expected, continue to analyze the data and make
adjustments as required. Monitoring continues on a regular basis, even after ownership is transferred to operations.

Working with Configuration Management

Configuration management serves the same purpose for a deployed solution that revision control serves for source code
under development-as a repository of state information regarding the actual components deployed as part of the solution.
Aspects of the configuration that are tracked include exact versions of software, precise contents of configuration files and
settings, exact system and network topologies, and so on. Operations personnel can use this configuration information to
control the deployment environment. Precise changes can be applied to the environment (and tracked in the configuration
management system), allowing the effects of those changes to be identified, understood, and controlled.

When deploying the migrated solution, it is vital for the Release Manager to provide all information required by the
operations team for tracking configuration information. Uncontrolled change in the deployed environment makes it very
difficult to understand and control the behavior of the deployed solution. Regardless of the size of a configuration change or
its urgency, the change must be tracked.

Checking Readiness to Deploy

Although the final decision to deploy involves several factors, the team makes the decision only after reviewing the test
results and information gained by using checklists. Reviewing the checklists alerts the team to any issues that may influence
the deployment. Although the lists are created to use before the actual deployment date, continuous review during
deployment is beneficial to ensure that all the suggested tasks are accounted for and to alert the team to needed
improvements in the organization of the process.

Not all of the listed items apply to every solution. Only the team knows which items are important to consider for its project.
The checklists are comprehensive and, therefore, may have many items that do not apply to each project. However, it is
always a good rule, regardless of the size or complexities of the solution, to review the suggested tasks and confirm that all
details have been considered.

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 6/16
04/03/2018 Chapter 6 - Deploying Phase

The checklists are not intended to be decision-making devices. If your team finds itself investigating the how and why behind
a specific consideration, it probably indicates that the project is not ready to move forward. All specific settings and
configurations should have been defined by the time the decision is made to move the solution to operations and deploy it.
If, upon reviewing the checklists, the team discovers this is not the case, the team should reconsider the decision to deploy.

Solution Deployment Considerations Checklists

A potential approach to take when going live is to review each layer of the architecture and run through the critical
considerations. The first three checklists address considerations relevant to the database tier, the application and business
layer, and the presentation layer.

Database Tier Considerations

This checklist lists issues to review when installing the database tier.

Table 6.3 Database Tier Considerations Checklist

Number Consideration Completed

1 Were database statistics updated prior to launch? Are database indexes fragmented? At  
what period will this be checked again, and corrected, if necessary?

2 Have all COM components been registered on their servers? Has the system run for  
long periods without failure or system resource issues?

3 Did the team define, test, schedule, and sign off on maintenance plans?  

4 Are database backups tested and online? Has restoration been tested on the same  
computer and on a different system? Are off-site backup procedures in place?

5 Are alerts defined for key problems and conditions? Who monitors the e-mail address  
to which these are sent? Are beepers used? Has the alert system been tested?

6 Are jobs defined for common tasks? Are roles assigned for emergency situations? Has a  
lead been defined for incident handling?

7 Has the latest build of the database from your development/QA environment to  
operations been migrated, installed, tested, and verified?

8 Has database security been addressed with appropriate logon accounts created? Is the  
system administrators (SA) account password blank? Are applications using the SA
account or other account(s)?

9 Have all relevant service packs been loaded to the operations databases? Are the OS  
and installed service pack level well known and documented in case of failure and
manufacturer support is required to be called in? Are security bulletins being
maintained and monitored?

10 Has clustering failover been tested in the operations environment? How long does the  
failover take to complete? Are all key decision makers aware of the time needed to
failover?

11 Has the operations database been loaded with clean data and have initial inventory  
levels been set? Have feeds from other systems been verified under load to ensure that
system availability is unaffected at the time they run?

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 7/16
04/03/2018 Chapter 6 - Deploying Phase

12 Is there a backup of the operations database as it stands the day before launch? Is it  
well known where this is stored?

13 Were data loads tested against the operations system? At what level (2x, 4x, 10x normal  
load)?

14 Has a disaster recovery plan (DRP) been established that includes database procedures?  
Who is the DRP team leader? Is the leaders contact information well known, and is a
contingency leader appointed?

15 Has a time increment been established for the transaction log dumping that will be  
sufficient to recover activity to the satisfaction of the business? Has it been tested?

16 Have backup power systems been fully tested to ensure proper operation?  

17 Are an appropriate number of replacement hard disks on hand in case of failure in an  

array?

18 Are the default client connection network library settings established on the server  
(typically, TCP/IP)?

19 Are all Database Application Server installation settings documented (sort orders,  
default language, and so on)?

20 Is the database running on the default port of 1433? If so, can this be changed to  
another port or ports to enhance security of the application without affecting proper
operation? If so, change it.

21 Are ancillary, non-essential SQL Server services running (MS Search, OLAP)? Stop them  
if not required.

22 Are databases installed on the server that are not being used? Remove them (pubs,  
Northwind, and so on be careful not to delete system databases such as model,
tempdb, master).

23 Are sufficient client access licenses and connections installed for the database server  
and the OS? Are these being monitored to assure that they do not reach their limit?

24 Is the database correctly tuned, and does it have the proper memory usage settings  
applied?

25 Is the database set for Auto Growth? Is disk space sufficient for the expected size of the  
data 6-12 months ahead?

Application and Business Layer Considerations

This checklist lists issues to review when installing the application and business layer.

Table 6.4 Application and Business Layer Considerations

Number Considerations Completed

1 Has the final release of your applications and components been given a release number,  

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 8/16
04/03/2018 Chapter 6 - Deploying Phase

been archived, and then deployed?

2 Were all required environmental settings for the applications set and documented?  

3 Were the proper security settings for the applications set and documented?  

4 Were the appropriate service packs for the environment applied and documented?  

5 Are all third-party software or components that are required by the system installed and  
documented (version numbers, vendor contact information, and so on)?

6 Are all the required DSNs for the applications defined and tested (correct net library  
settings are being used)?

7 Has connectivity between the middle-tier system and any back-end systems been  
tested? Under load? Monitoring of connection pooling to assure proper operation?

8 Are operations configurations for this tier backed up? Were scripts created to reset  
configurations in an emergency, or to bring up a new server? Are they in a well-known
location?

9 Are the activation types for your COM+ application set properly? Has the application  
been tested with the consoles logged on and logged off to assure the proper identity is
used? Have bogus transactional calls been attempted to simulate rollback integrity?

10 Are the queuing settings for your COM+ application set? Have calls into the queue  
been monitored through the cycle to assure they clear

11 Are you sure that no active debug code or logging exists in the operations  
components?

12 Has debugging in the COM+ application properties window been turned off?  

13 Has server communication between servers been checked to assure that proper DNS  
resolution and routing, in case of multiple network interface cards (NICs), is happening?

14 Are spare disk drives and NICs available on-site?  

15 Has security logging been implemented? Has impact on the system been assessed?  

16 Have all non-essential services and open ports on the server been identified and  
closed?

17 Have any and all event log messages been identified and investigated?  

Presentation Layer Considerations

The following checklist lists issues to review when installing the presentation layer.

Table 6.5 Presentation Layer Considerations

Number Considerations Completed

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 9/16
04/03/2018 Chapter 6 - Deploying Phase

1 Are the IIS server properties configured? Is a script available and stored in a well-known  
place to reset the application settings or to bring up a new server?

2 Have the secure socket layer (SSL) tokens been applied, as needed? Are the tokens  
backed up onto portable media and stored in a well-known place for emergencies or
new server configuration?

3 Are any certificates that might be required loaded? Are the certificates backed up onto  
portable media and stored in a well-known place for emergencies or new server
configuration?

4 Has the latest release of the ASP code, images, and HTML files been given a release  
number, been archived, and then deployed?

5 Was an external connection used when testing the application against the operations  
system? The external connection should be similar to what a customer will use.

6 Are the appropriate DSNs for the ASP code set up and tested?  

7 Have the unnecessary ISAPI filters been removed?  

8 Are the custom error messages for IIS set?  

9 Is the appropriate level of directory security set  

10 Are the performance tuning properties for IIS set, documented (preferably scripted), and  
stored in a well-known place?

11 Are the appropriate operators for the server set?  

12 Are the execution permissions and application protection levels set?  

13 Have you enabled/disabled application logging, as required?  

14 Does the OS have sufficient client access licenses for the expected peak traffic loads?  

15 Have you checked your Personalization and Membership (P&M) settings and assured  
that they are appropriate for your solution? Is LDAP required to be accessible to the
public? If not, is it blocked at the firewall? Is Anonymous access to LDAP disabled?

16 Has the team checked the LDAP settings for its LDAP services?  

17 Has the team loaded the appropriate P&M schema settings for its solution in P&M?  

18 Has the team mapped its Web servers to the proper P&M instance?  

19 Has the team loaded the appropriate Site Server pipeline components onto its servers  
and the related pipeline configuration files? Are permissions on these files (as well as
any .csc files) set so that users cannot download these files? Were all .csc and .pcf files
(and dependent VBS scripts) examined to assure that they contain no clear text
credentials for servers or databases?

20 Has the team set the default pipeline component settings?  

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 10/16
04/03/2018 Chapter 6 - Deploying Phase

21 Has the team installed the proper scriptors for its pipelines, if it is using them (see #18  
for security considerations)?

22 Has the team applied all metabase or registry settings required to improve  
performance?

23 Have all non-essential Web server instances been disabled and/or removed from the IIS  
application?

24 Have all non-essential SMTP server instances been disabled and/or removed from the  
IIS application?

25 Have all non-essential FTP server instances been disabled and/or removed from the IIS  
application?

26 Will the IIS Web-based administration be used? If not, disable or remove it from the  
Web server configuration.

27 Are any IIS samples, or any other manufacturer sample code, present on the server?  
Remove them prior to launch.

The next section of the Solution Deployment Considerations Checklists reviews technical issues that apply to the overall
solution and business issues that could affect the solution. Again, the team should consider the specifics of the solution
before deciding if any single item applies to the situation.

General Technical and Business Considerations

Note: The following suggested checklist should be supplemented with checklists specific to the migration solution.

Table 6.6 General Technical and Business Considerations

Number Considerations Completed

1 Has the team removed "Guest" accounts from the system and checked to ensure that  
this does not affect the application?

2 Has the team double-checked the operations network infrastructure against the  
architecture?

3 Has the team confirmed that no network equipment is in test or debug mode (such as  
routers, switches, hubs, load balancers, and so on)?

4 Has the team properly configured caching engines with the proper information?  

5 Has the team applied any required operating system service packs and documented the  
OS version and service pack level accordingly?

6 Has the team tested operations integration with third-party systems?  

7 Has the team finalized training of the operations teams?  

8 Has the team put in place change-control procedures for the operations environment?  

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 11/16
04/03/2018 Chapter 6 - Deploying Phase

9 Has the team finalized the operational processes and guidelines?  

10 Has the team limited the access of anonymous users to appropriate content  

11 Has the team developed, tested, and simulated disaster recovery procedures? Are the  
appropriate lead roles assigned to individuals or project positions?

12 Does the team have procedures for contacting key decision makers in the event of a  
major problem or security threat?

13 Has the team created a backup of the operations code, data, and content?  

14 Has the team tested backup power systems and assured they are online and fully  
charged?

15 Has the team tested the operations server farms for response to the removal or addition  
of servers?

16 Has the team considered issues related to physical security?  

17 Does the team have a plan for quick-fix engineering in the event of a problem during  
the launch period?

Core Solution
Most solutions include a number of components (for example, individual products and code components), as well as
infrastructure (for example, servers and other resources), that provide the framework or backbone for the entire solution.
These components do not represent the solution from the perspective of a specific set of users or site, but the deployment of
the solution to sites or users generally depends on this core set of features or technology. Examples include the domain
controllers, mail routers, remote access servers, and database servers that any site deployments depend upon for the full
functionality of the solution.

Depending on the solution scenario, the core technology may need to be deployed before or in parallel with site
deployments. Deploying components includes the following tasks:

Configure systems

Load and configure software

Prepare physical locations

Mobilize configured hardware

To avoid delays, core solution components may be reviewed and approved for deployment in advance of other parts of the
solution still being stabilized. Operations staff must feel confident making this commitment before the whole solution has
been proved to be stable.

Interim Milestone: Core Technology Deployed

After the deployment of the core technology, all components upon which the remainder of the solution (yet to be deployed)
depends are in place, running properly, and stable enough to move forward with any dependent or site deployment
components.

Site Deployment
At this point the solution has the key features and components in place to enable usage of the technology. There may be
off-site deployments that still need to take place, but those components dependent upon the core solution are now working
and in the process of final stabilization.

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 12/16
04/03/2018 Chapter 6 - Deploying Phase

After any core solution components are deployed, any site-specific components are now enabled to complete the solution
features and enable all targeted users to have access to the solution.

Customer and user feedback might reveal some problems. The training may not have gone well, or a part of the solution may
have malfunctioned. Certain solution deployments may need to be revisited based on feedback from site satisfaction surveys.

To reach the Site Deployments Complete Milestone, the team makes a concentrated effort to finish deployment activities,
stabilize and close out the project. This milestone is applicable only for projects that involve client-side deployments.

Interim Milestone: Site Deployments Complete

At the completion of this milestone, all targeted users have access to the solution. Each site owner has signed off that the
solution is operating, though perhaps with some issues.

Top of page
Stabilizing the Deployment
Stabilizing the solution is a joint venture between the project and the operations teams. Stabilizing usually begins in the later
part of the Stabilizing Phase and continues throughout the Deploying Phase as each solution component is put in place.

It is important to include time in the master schedule for deployment stabilization because it gives both teams an
opportunity to fine-tune the solution, resolve any issues that might arise, and monitor the solution to ensure it continues to
work properly after going live. It also allows the project team to assist the operations team after the transfer of ownership.

It is to be expected that some issues will arise with the various site deployments. These issues should be continuously tracked
and resolved.

At the Deployment Stabilized Interim Milestone, the customer and team agree that the entire solution is operating
satisfactorily.

Disengagement Considerations
It can be difficult to determine when a deployment is complete and the team can disengage. Newly deployed solutions are
often in a constant state of flux, with a continuous process of identifying and managing production support issues. The team
can find it difficult to close out the project because of the ongoing issues that will surface after deployment. For this reason,
the team needs to clearly define a completion milestone and criteria for the deployment rather than attempt to reach a point
of absolute finality. Usually one or two members will remain on the project for a short period of time (agreed to by the two
teams) to follow through on any problems or undocumented instructions.

If the customer expects members of the project team to be involved in ongoing maintenance and support, those resources
should transition into a new role as part of the operations and support structure after project close-out. At this late stage,
team members and external stakeholders will likely begin to transition out of the project.

Part of disengaging from the project includes transitioning operations and support functions to permanent staff. In many
cases, the resources to manage the new systems will already exist. In other cases, it may be necessary to design new support
systems. Given the scope of the latter case, it is considered as a separate project.

The Quiet Period

The period between the Deployment Stabilized Interim Milestone and Deployment Complete Milestone is sometimes
referred to as a "quiet period." Although the team is no longer active, team resources will respond to issues that are
escalated to them. Typical quiet periods are 15 to 30 days in length.

The purpose of the quiet period is to measure how well the solution is working in normal operation and to establish a
baseline for understanding how much maintenance will be required to run the solution. Organizations using Microsoft
Operations Framework (MOF) will measure the number of incidents and downtime and collect performance metrics of the
solution. This data will help form the assumptions used by the operations Service Level Agreement (SLA) on expected yearly
levels of service and performance. For more information on SLAs, see the MOF Operations Guide for Service Level
Management that is available at http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx. It is listed with
other Service Management Functions under Microsoft Solutions for Management.

Top of page
Transferring Ownership to Operations
https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 13/16
04/03/2018 Chapter 6 - Deploying Phase

The point in the Deploying Phase when ownership of the solution is transferred to operations may vary. In large enterprises,
the point will occur well before the solution goes live because the operations and IT teams completely own and manage the
production environment. However, a smaller company may see the development team owning the solution well after it goes
live. Another possibility of differing transfer times is when solution hosting, such as in an Internet solution, has been
outsourced to a hosting vendor, and the hosting company owns many of the operational issues.

Whatever situation occurs, there is a time when ownership moves to operations. At that agreed-upon time, the project team
must complete its final tasks, gather all produced collateral, and transfer it and the technology to operations.

Transferring the Solution

Both teams will be very busy during this time. The project team will be closing any open issues and handing off maintenance
activities to the operations team. The operations team will be initiating procedures and validating all collateral and
equipment received from the project team.

Project Team Tasks

The project teams closing tasks might include:

Verifying that the operations team has the proper resources to maintain and manage the new solution. Some
companies have an operations department ready to immediately take over. However, some companies may have to
secure and train employees to manage their operations and support teams.

Confirming the final transfer of the knowledge base to the operations team.

Reviewing operations logbooks and ensuring that the procedures are being properly performed. The development
team should clarify and correct any irregularities that were logged and ensure that these activities are being
maintained and monitored on a daily basis.

Reviewing configuration management data for the deployed solution to ensure that any changes in deployed
components are accurately reflected.

Confirming that all project sign-offs are correct. Once the signatures are secured, the transfer of ownership starts, and
the operations team is solely responsible for the solution.

Operations Tasks
During the transition period, the operations team will work closely with the project team and complete the following
activities:

Activate all reporting systems.

Validate and publish all collateral.

Validate and publish the knowledge and databases.

Review training materials provided by the project team.

After these activities are complete, the project team transfers the solution and documentation ownership to the operations
team. However, a member of the development team will usually remain available for an agreed-upon time to assist the
operations team in its early maintenance endeavors. The development team will sometimes remain on the support list and,
should a crisis occur that requires additional support, the development team might be called upon to assist support (help
desk), the operations team, and management personnel.

Interim Milestone: Deployment Stabilized

At this milestone, the solution is deployed and has reached a quiet period where the operation of the solution is under
control, users have started to receive business value from the solution, and the project is transitioning to closure.

Top of page
Project Review
https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 14/16
04/03/2018 Chapter 6 - Deploying Phase

The product manager and program manager take the lead in compiling the closeout report. The team and customer can use
the closeout report as a quick reference to the work performed during the project and as a basis for future planning.

Signing Off on the Project

Once all the deploying tasks are complete, the team must formally agree that the project has reached the Deployment
Complete Milestone and that the projects work is finished. By approving the milestone, team members signify that they are
satisfied with the work performed in their areas of responsibility. As before, project teams usually mark the completion of a
milestone with a formal sign-off. The sign-off document is a project deliverable.

Obtaining Customer Sign-off

Upon project closure, the product manager obtains the final sign-off from a representative of the customer, signaling
approval of the solution and permission for the team to disengage from the project. Although, at this point, the team is busy
informally closing outstanding tasks and wrapping up deployment, the sign-off should be a formal acknowledgement that
the project is complete.

Producing the Closeout Report

The closeout report is the final physical deliverable of the deployment. It includes:

Final versions of all the major project deliverables (for example, vision/scope document).

User information summary.

Project review meeting summary.

Sign-off by the team.

Sign-off by the customer.

Summary of next known steps.

Conducting the Project Review

When the project is complete, the team should hold a review meeting to discuss the project and identify what went well,
what did not go well, what to replicate in future projects, and what to change. Without assigning blame, team members
conduct the project review with the goals of learning from mistakes and improving future projects. Often called a
postmortem, or post project review, the review meeting sometimes takes place shortly before the end of the project rather
than afterwards, because team members might be required to leave the project before it ends.

Top of page
Closing the Deploying Phase
Closing the Deploying Phase requires completing a milestone approval process. The team needs to document the results of
the different tasks it has performed in this phase so that the customer and other key stakeholders have sufficient information
to sign-off on completion of the phase.

Key Deliverables from the Deploying Phase

A deliverables checklist for the Deploying Phase includes:

Final versions of all solution documents, code, and test cases

Training documentation

Service Level Agreements

Operation and Support Information

Customer/user satisfaction data

Project close-out report

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 15/16
04/03/2018 Chapter 6 - Deploying Phase

Definition of next steps

Updated risk management

Milestone review report

Team member project progress report

Team lead project progress report

Top of page
Key Milestone: Deployment Complete
The Deploying Phase culminates in the Deployment Complete Milestone. By this time, the deployed solution should provide
the expected business value to the customer. The customer must agree that the team has met its objectives before it can
declare the solution complete and close out the project. This requires a stable solution, as well as clearly stated success
criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place.

Reaching this milestone means the project team has successfully transitioned the solution to operations. There may be
ongoing work that certain members of the development or project team continue to be engaged in, but as a whole the team
has officially made the transition to close the project.

Top of page
Download

Get the UNIX Migration Project Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Top of page

© 2018 Microsoft

https://technet.microsoft.com/en-us/library/bb497043(d=printer).aspx 16/16