The Foundation of a Data Center Migration Project

Each of these five building blocks fit with the others to form the foundation of a successful data center migration project.  The details that follow describe the importance of each building block for a data center migration project.  Data center decision makers can use the information to assess their potential impact on business operations.

A data center migration project team should include three groups: the core team, technical subject matter experts (technical SMEs), and the business organization.

Your core team provides continuity for the project.  They include the project manager, virtualization architect, network engineer, migration analyst, and a storage architect.  They must have past experience with data center migrations and are the force du jour, architecting the right solution and keeping the project on schedule and on budget.

Technical SMEs may or may not be dedicated full-time resources to the migration project but are essential to your migration strategy.  They matriculate into the core team when their expertise is required.

With only a few exceptions, neither the core team nor technical SMEs must originate within the organization.  Sometimes resource availability is limited due to day-to-day IT operations and projects.  Often, an enterprise will have organizational strengths in some areas and less so in others.  It is important to determine what resources are available in-house and which require the help of outside expertise.

None-the-less, there are four in-house resources whose availability is necessary: a project manager, a disaster recovery coordinator, a data center services/operations expert, and an executive sponsor.  While each of their roles is distinctly different, their corporate knowledge is vital to the overall success of the project. 

• Business Layer
• Application Layer
• Infrastructure Layer
• Interdependency Across Layers

A discovery process identifies the interdependencies by documenting them via a dependency mapping exercise.  It should be deployed for each data center site and across sites.  It helps an organization understand the interactions between the layers.  It reveals where SLA agreements would not be met or where service interruptions would occur, if entities were to be migrated separately.  

During the process, an organization can run the risk of either missing critical information or wasting huge amounts of time and money collecting and mapping absolutely everything.  But if executed properly, it helps to minimize risk and the migration project’s impact on daily business operations.

A data center migration affects mission-critical business operations, and a migration-specific methodology helps ensure operational stability and business continuity and should include:

• Phase 1: Initiation
• Phase 2: Discovery
• Phase 3: Planning
• Phase 4: Execution
• Phase 5: Close-out

The following is a summary of the data center migration methodology.  It includes a baseline of over eighty deliverables and a migration toolbox with over fifteen proprietary tools.

Phase 1: Initiation

The initiation phase launches the beginning of an organization’s data center migration and an internal dialogue about the following:

• What is your business case?
• What type of data center migration should you execute?
• What is the scope of your migration and its charter document?
• What is your resource plan and high-level timeline?
• What is your communication plan for stakeholders?
• Have you identified your organizational constraints and action plans to redress them?

Phase 2: Discovery

The discovery phase primarily identifies and documents physical and application inventory.  Incomplete and incorrect data will cause delays and serious problems with your migration. In discovery, an organization determines:

• What data is important to collect
• How to document and manage the data
• What tools to use
• Key technical and timing dependences
• What assets to retire

Phase 3: Planning

The planning phase formulates an organization’s assets into move groups and coordinates logistics for the physical and/or virtual move(s).  The goal is zero impact on operational stability and downtime.  In the planning phase, the following should be completed:

• Procurement activities completed and transportation needs arranged
• Move groups identified
• To-be diagrams prepared
• A detailed project schedule prepared
• A run book prepared
• All interactions and interdependencies between assets identified
• A communication plan created for affected stakeholders

 ¹ Gartner RAS Research Note G00236380 Data Center Migrations — Five Steps to Success, David J. Cappuccio, 26 March 2014

Phase 4: Execution

The execution phase is the culmination of all discovery and planning efforts.  It is in the execution phase where your previous work is validated.  To mitigate risks, migrate from steady state to steady state.  Scrutinize these details:

• Have you conducted a “pilot migration”?
• Is your go/no-go process firm?
• Will you be virtualizing over the wire?
• Are you prepared for final system backup and takedown?
• Are you ready for physical pack, transport, and re-staging?
• Are recertification and acceptance testing processes ready?
• Are you consistently communicating to your stakeholders, employees, and vendors?
• Are your contingency plans in place?

Phase 5: Close-out

The close-out phase is a technical transition support period.  Physical assets and the site of origin are decommissioned.  The attractive financial benefits of the migration may not be attained unless disposition of assets, both physical and staff, are implemented. Take steps to:

• Identify the retired hardware should stay behind in case of post-migration issues
• Update all vendor agreements 
• Train staff on the new processes
• Update and test the DR plan
• Execute any staffing adjustments
• Conduct and document a lessons learned meeting

Risk is an inherent part of every data center migration project.  Managing those risks must be a core discipline from the beginning of the project to its conclusion.  The top priority is to identify risks, to mitigate them when possible, and when it is not, to minimize their impact.

A healthy risk management process should be intentional and include these stopgap efforts:

1. Identify specific project risks unique to your culture and environment.
2. Evaluate each risk, understanding what triggers the risk and analyzing the probability of it becoming a reality.
3. Prioritize and quantify each risk to understand its impact on cost, schedule, and business operations.
4. Develop mitigation plans to prevent the occurrence of each risk, and establish a contingency plan to execute in the unfortunate event the risk materializes.
5. Risk re-assessment is an ongoing effort via project reviews, milestone reviews, and “look ahead” meetings.

Sometimes it boils down to risk acceptance and/or tolerance.  Can you manage the potential impact of the risk should it become a reality?  Is the cost too high?  Do not be afraid to accept reasonable risk when budget numbers or timelines are not syncing.

Recommendations to Reduce Risk

• To minimize the impact on operational activities, prioritize the migration order of your move groups by examining technical constraints, cost, and complexity.
• Always schedule a primary move date and a fallback move date, as well as multiple iterative meetings with application owners, database administrators, and server team members along the way.
• All high level risk issues in your contingency plans should have a well-defined path to resolution that starts with the project manager and escalates to the executive team, if/when it is required for resolution.
• Document mitigation and contingency plans, and communicate them to your stakeholders early and often. These efforts encourage organizational buy-in and precludes what no one likes — surprises.