• 06/03/2014
    7:00 AM
    Irwin Teodoro
  • Irwin Teodoro
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Data Center Relocation: Tips For Success

Moving a data center is a costly, high-risk project. Follow these DCR recommendations for a smooth move.

Can one article tell you everything you need to move a data center? Maybe not, but extensive planning can substantially improve your odds. This aligns with one of my own "75/25" rules about data center relocation (DCR): Spend 75% of your time on discovery and planning and 25% on actual execution of the move.

There's a caveat, though. DCR success is not just about planning. It's about the detail and breadth of your plans. Here are some recommendations to keep in mind.

DCR methodology and leadership
A data center move is a costly, high-visibility, high-risk IT project. To avoid impacting your company's bottom line with unnecessary costs, downtime, and added confusion, you need to treat it as such. More than labeling equipment, scheduling application downtime, and technology refreshes, a successful DCR project includes:

  • Following a detailed DCR methodology. This walks you through the details, deliverables, steps, and signoffs before, during, and after the actual move.
  • Strong executive sponsorship. DCR requires an internal champion who can help the team surmount political, operational, or budgetary challenges.
  • Getting the right people. Success requires a seasoned DCR project manager and a dedicated DCR team. DCR may also require backfilling or reassigning key infrastructure positions. It also involves connecting disparate teams together: application owners, infrastructure teams, external vendors, and end users.

DCR application planning
Given the myriad details surrounding physical hardware, cabling, and the new facility's floor and rack design, it can be easy to lose focus on another key to DCR success: planning the move from an application perspective. For the least impact to users, focus first on the applications in use, their application dependencies, and the surrounding environment that supports them.

Figure 1:

DCR best practices on application planning include:

  • Take time for application discovery. A large portion of your planning should surround application and environment discovery. This includes quantitative work (i.e., use of third-party discovery tools). It also includes significant qualitative work (i.e., interviews with application owners and end users). This will reveal many dependencies you need to consider.
  • Identify and bundle. Your discovery work should unearth dependencies and relationships between applications, their underlying databases, and infrastructure elements. It's often best to bundle and move these interdependent elements together, especially if separating them risks unexpected downtime. Consider using a bundling algorithm that tracks and schedules these elements together.

Migration methods
In keeping with our application focus, you also need to devote time to evaluating and choosing the different methods to migrate your applications and data to the new data center. A number of migration methods can be used. Each has its own benefits and risks. Here are some of the most common methods:

  • Virtual migrations. This is the least disruptive method, involving point-and-click migration of virtual servers already running in the environment. For many virtual server environments, this method may cover as much as 50% of the applications moved. With added optimization work on the virtual environment, this can grow to as much as 65% application coverage. (One caveat: This method works best in VMware hypervisor environments based on the Microsoft Windows or Linux operating system.)
  • Pick up and ship. This is the most disruptive method. It involves shutting down, moving, and restarting the physical server(s) at the new data center. It is best suited for low-risk applications.
  • Shut down and restore. This is another method that involves restoring the operating system on to new or repurposed hardware. It is well suited for physical servers and other (non-VMware-based) virtual server environments with longer downtime windows.
  • Application failover. This method involves failing over the application database to the new data center. It is used as an adjunct to one of the other methods, since it does not involve moving the application servers themselves. This method uses an application-upgrade approach and benefits from minimal downtime.

The planning and discovery stage of your upcoming data center move doesn't need to be overwhelming. Stay on track with a clear DCR methodology and the best practices listed above. Each milestone and event on your roadmap can then develop naturally, with its own built-in checks and balances.


change control

Hi Irwin -- How important are change control procedures in DCR application planning and the overall process?

Re: change control

Hello Marcia, yes ensuring proper change control is paramount to the success of the engagement.  with all the moving parts and dependencies therein it is important that a strict change management is followed, AND most importantly captured in your migration project plan.  In some cases you might have to accelerate the process in order to meet crucial deadlines as set forth by the business units....

Re: change control

Thanks for those details Irwin. I'm curious, what scenarios do you see most often that lead organizations to move a data center?

Re: change control
Hi Marcia I have seen a few Data Centres for a few companies move over the years and can suggest a few reasons based on those experiences. One is consolidation of services. Between mergers, takeovers and the selling of divisions, corporations can end up with multiple small data centres or else sharing facilities with other companies and wish to consolidate components. Another is the political and social atmosphere in the region. In the 70's and early 80s a great many companies in Canada moved from Quebec to Ontario and New Brunswick due to concerns over the seperatist movement. but the two biggest reason are 1) the current facility may not meet your projected needs going forward. You may not have the space available to expand the floor or the cost of upgrading your infrastructure may be too high. And big reason 2)just plain property value. Your data centre may have been in a fairly remote location when it was built in the 80s but urban sprawl has since surronded it with with other businesses and caused the property values to sky rocket. So the appeal of turning the space over to other uses combined with incentives being offered by another region could make relocation logical. One key thing to remember though is while Irwin appears to talking about moving entire data centres, the principles apply exactly the same if you are talking about moving smaller components such as your web hosting services or file services as well and these are much more common.
Re: change control

That's really interesting Clifford, thanks for the insight! I thought consolidation and growth requirements would be drivers, but I hadn't considered political/social factors. Along that line, have you seen privacy laws affecting data center moves?

And good point about the principals applying to the smaller components; it does seem like those would be more common scenarios.

Re: change control
Actually I hve seen data centres kept from moving for exactly that reason but it comes into play far more often when discussing support for the data centre particularlly in these days of lights out data centre and follow the sun operational support.
Re: change control

I see. I was thinking in terms of personal data privacy laws -- seems that data center location can be an issue for cloud service providers with customers in regions with more stringent personal data privacy laws.

Re: change control

Hmm...this is the same project that resourced out to the staffing firms looking to pay low hourly rates as 'all inclusive' and the economics didn't work at that time as they needed to pay more for experience in that data center migration in Oregon. Penny wise and pound foolish. How much would they have saved if they spent more on the resources to do it right?

Re: change control

Rubyliu, what project are you referring to? Can you provide more details?

Smooth Migration

In addition to physical resource planning, I want to mention about logical planning, design and migration.

As indicated in the post virtual migration might be smooth, actually If data centers close enough, migration might be almost seamless. Between the data centers interconnect link can be purchased for short amount of time and all the networking devices ( assume there is no single point of failure ) can be shifted to another data center.


Then both data center for s short amount of time will work on single point of failure but meanwhile application load can be started to migrate.

Depends on the Data center interconnect link capacity of course; application load can be carried from old data center to new one.


Out side work needs to be consider of course such as DNS , BGP announcements so on but with the help of Load balancer and proper routing design migration might be done smoothly.

 There are many things need to be written to show how such as protocols,vendor specific implementation so on but this is already long comment I believe.