How to move a datacenter: 5 essentials for success and peace of mind in a datacenter relocation project.


There are few endeavours that are more delicate and risky as moving a datacenter. Here are five concrete aspects that you will find useful when embarking on a datacenter relocation project.


Assessing complexity

When considering a datacenter move, the first temptation is to characterize it by the number of servers, applications or hardware assets. “It is a 500 server datacenter move” tells you very little about the complexity and scale of the project. Moving 50 servers can often be more challenging than moving 500, depending on factors like:

  • How tightly interrelated are one with the other?
  • How critical is the response time between them?
  • How well documented are these dependencies? Is this documentation updated? Sure?
  • Are there any legacy systems involved? Is a subject matter expert (SME) available?
  • Are there any mission-critical applications involved?
  • Are clients’ systems connecting directly to your infrastructure? Do you have appliances or servers in your datacenters that pertain to your clients?
  • How challenging are your Service Level Agreements?
  • How much time do you have for planning and execution?
  • In principle, can the move be done in parts or do you absolutely need to do all in one shot?
  • How flexible is your financial and budgeting systems, should your project need to spread over more than one fiscal or calendar year?
  • Are you willing to explore opportunities for refresh, update, virtualize or move to cloud services as part of the project? Is there time and money for it? Is the additional risk acceptable?


The services approach

This is why rather than thinking of your project in terms of servers, boxes or assets that need to be moved, you want to approach it from a perspective of business services. Yes, you will need a detailed inventory of all those assets, but it is much more critical to have a detailed catalog of the business services and internal services that depend on the infrastructure you are planning to relocate.

The catalog should be as granular as you can and completely oriented to the business or internal services they provide. Later on the road you can simplify that list and of course you will need identify the dependencies. However, the items to move in your main list should look more like “monthly billing service”, rather than “App server A, DB Server X and printers Y and Z”.
Working with SMEs, you should be able to map every business service involved. Data flows should be clear for every single service, touching absolutely all assets that take part in it. Application servers, database servers, networking equipment, security devices, peripherals, cloud services, other external services like external storage and even people, if any of your services require some manual intervention. When you are doing the move, you want to make sure everything and everyone is in place.

The services approach will not only reveal the full list of items involved, it will also reveal the constraints and opportunities linked to moving any individual part of the service chain. For instance, you will see if there are any systems that absolutely need to be on the same LAN to get appropriate time responses, as well as those that offer an opportunity to be moved separately, which may help distribute efforts in phases or waves, in order to reduce risks.


Time and financial dimensions

When you first approach the possibility to move a datacenter, unless the infrastructure and applications are very recent or very simple, it will be hard to know whether the project can take more than one year. In industries likely to have complex infrastructure, tight security and legacy systems, like financial institutions, just the detailed assessment can take 6 months or more.
If you have SLAs with clients and especially if those clients’ systems connect to yours, you may need to advise of any changes to your infrastructure. If the relocation will require to their configuration, you may need to advise several months before you can touch the first cable. Ordering and delivering new services, like telecommunications at the new location, can also add months to your timeline.

Finally, you need to consider that budget discussions take place many months before the beginning of the fiscal year. So, it is important to have full support from executive management in order to accommodate multi-year budgeting and healthy leg-room for unforeseen work that cannot be uncovered by an initial high-level assessment.


Risk management and relocation strategy

The datacenter relocation finds its perfect analogy in that of the car being repaired while you drive. Few projects offer a bigger challenge for IT project managers in terms of risk management. You have technical, financial, security and human-based risks that need to be identified and managed.
Some industries are more risk-averse than others. This aversion tends to perpetuate pieces of hardware and software that sustain the most critical services. This is why in industries like finance you will often find black boxes that nobody wants to touch, as they have been working well for many years. Sometimes decades. And finding the documentation and SMEs that can support the endeavour of relocating are usually scarce.
Once you have a detailed assessment, you will be in position to start the risk management process. AT that point it will start to be clear what options are feasible in order to disperse the risks through across different phases. You will rarely have enough resources available to do a high complexity relocation in one shot, because you don’t want replacements at the time of the move. You want only the top-notch technicians and SMEs focusing on delivering every aspect of each service to perfection.
Because of this, you will often want to spread the risk across different phases if your assessment reveals that it is a feasible approach. In a perfect world, you will want the new datacenter to mirror your current infrastructure in every aspect before you move. Same OS, same versions for all software, same model of servers and appliances, etc. This should allow you to test all new infrastructure with enough time to perform any final adjustments before even touching your current datacenter.
In real life, you rarely have that luxury. Budgetary constraints, architecture and even availability of identical or equivalent equipment, may make a perfect mirroring impossible. This is why you will need to make a decision from a large menu of possibilities, which can be boiled down to the following main options:
1. Move original equipment and test.
2. Use your Disaster Recovery platform as a temporary solution, while completing the move.
3. Mirror services with new equipment without changing architecture and sourcing approach.
4. Redesign the way services are provided, assessing opportunities for virtualization, cloud services and changing sources of services.

1. Move original equipment and test
This is clearly the most risky approach, but that does not mean it cannot be considered. As long as you have a solid strategy in place to support those same services from an alternate location, for example, this option could be the most cost-effective and the best choice when moving small datacenters. For instance, small equipment rooms or datacenters supporting the connectivity and back office in a branch office, where systems in another branch may be configured to temporarily handle the extra load.

2. Use your Disaster Recovery platform as a temporary solution, while completing the move.
If you have a DR strategy in place, using it as a temporary solution is an option you want to look at. This frequently means running reduced services for a while and have the additional complexity and risk of migrating data to and from your DR site before and after the move.
It is certainly not the ideal scenario, but it may be one you can use alone or in combination with the other approaches to deliver a transparent or nearly-transparent relocation.

3. Mirror services with new equipment without changing architecture and sourcing approach.
This can be, by far, the safest approach in most cases. You replicate the environment in the new location and, if your applications allow for that, can even get them running in parallel before decommissioning the old servers.
However, this approach is rarely available to all as it is one of the most challenging from a budgetary perspective.

4. Redesign the way services are provided, assessing opportunities for virtualization, cloud services and changing sources of services.
In an ideal world, you don’t want to add complexity -and risks- to an already delicate endeavour like a datacenter relocation. Thus, a datacenter relocation is not the best moment to rethink architecture and assess new ways to deliver your services. However, constraints of all kinds might push you in this direction, ate least partially.
As explained before, timing is everything when it comes to a datacenter relocation. Identifying the main challenges at the early stages, might give you the space you need to assess and test changes in architecture design on time, so you can have make of your relocation an opportunity to further advance your platform roadmaps and unveil opportunities for more cost-efficient sourcing.



The human dimension.

I am convinced that one of the most underestimated components in any technology-driven transformation is the human dimension. Unless your relocation can be done entirely without the participation of your internal staff and without altering any part of your current infrastructure (except location, of course), chances are that you will be touching multiple interests and sometimes facing opposition in different forms and intensities.
Even in the most professional settings, you might find the human factor as the enabler of great opportunities, but also as the root of some very real risks. You might want to be especially careful of identifying from the beginning:

  1. Stakeholders that play an active role in the delivery of a service. We all know stories about the office “heroes” who never take vacations because their intervention is critical to keep the business running. Getting their full and timely cooperation might be difficult as they are always overwhelmed by the day-to-day operations.
  2. Providers affected by your decisions to relocate or change approach. This is an obvious one. If your decision is taken and your contractual framework allows for it, this should not be a problem… in theory. However, you might find resistance in the form of special offers and tempting proposals that will make you spend time in assessing their continued participation under a different form or with a different service or product. Be careful with the time you devote to these efforts to continue in making business with you.
  3. Client organizations and final customers. Never underestimate the impact that a seemingly internal decision might have in public perception. Relocating using a strategy that might affect local businesses and jobs, for example, can bring headaches, as well as stress your timeline. An example could be the push-back from Canadian society to the way a major bank introduced an outsourcing model for part of their IT services in 2013.



Keep in mind that during the assessment, planning and execution of a datacenter relocation, an extensive amount of highly-sensitive information will be being shared among many of the stakeholders. Also, an unusually large number of organizations and individuals will need to be aware of the days and hours where your infrastructure will be in the process of being moved and reconfigured. In other words, they will know the exact moments when your guard might be low.
Thus, you want to take especial care to enforce security measures in order to keep all documentation confidential. And don’t forget to apply these same measures to your backups and other media.


Leave a Reply

Your email address will not be published. Required fields are marked *