Datacenter Migration How To and Checklist

Datacenters are among the most complex and technologically advanced entities on the planet, with very complex systems, architecture, and network intricacies. What is a datacenter? Datacenters are dense concentrations of compute, storage, and network resources housed in a facility that provides resilient environmental, power, and network redundancy. Datacenters can be privately owned and managed, or they can be publicly owned with many privately managed “pods” of computer/server/network resources that are sold to various organizations. With all of the complexities involved with datacenter resources, there may be reasons that an organization decides to migrate from one datacenter to another datacenter. What are reasons for datacenter migration? What complexities and challenges are involved with doing this? What planning needs to happen beforehand? What needs to be documented? Is there a checklist that we can use to perform the datacenter migration successfully?

Reasons for Datacenter Migration

The reasons for migrating from one datacenter to another may be as complex as the datacenter themselves, however, generally speaking, there are a few reasons that you may decide to migrate resources from one datacenter to another ranging from business needs to technology needs. From a business perspective, there may be reasons that a datacenter migration makes sense whether it is a merger, acquisition, rightsizing resources, downsizing, or scaling out. Additionally, organizations may look to scale out from a high availability perspective and shift resources to various datacenters based on business needs.

Datacenter Migration

As far as technology is concerned, datacenter technology is constantly changing and moving forward. There may be technology reasons for moving from one datacenter to another to improve features, and/or functionality. Additionally, an organization may decide to spread out resources across multiple regions to improve performance and resiliency of resources. Regardless of the exact reason for migrating datacenters, the complexities and processes that must be considered remain ever important to making sure the shifting of resources happens seamlessly without end users recognizing any outage or degradation in performance or service.

Establishing the Criteria and Goals of the Migration

The criteria and goals for datacenter migration can vary based on what business needs are or what the problem is that is trying to be solved with the migration. If the datacenter migration is only a partial migration to shift a subset of resources this will change the landscape of the migration versus migrating all resources from one datacenter to another datacenter.

Make sure to assess the criteria and goals of not only the technical aspects of the project but also the business goals of the project. This can help with making sure the business goals and impacts are thought through along with the technical goals.

What if we are migrating our current datacenter resources to the public cloud?

Public Cloud or Private Datacenter?

For many organizations, a datacenter migration may mean migrating from one private datacenter to another private datacenter. However, with the trend among organizations being moving more resources to the public cloud, a datacenter migration may mean moving from a private datacenter up to the public cloud via one of the public cloud vendors such as Amazon AWS, Microsoft Azure, or Google Compute Cloud.

Public Cloud Vendors

There are different challenges with each migration that will need to be considered. With moving to public cloud, there will of course be no physical resources that will be moved, only virtual or logical resources. With physical private datacenter migrations to another private datacenter, there may be physical resources and assets that will be moved.

An example of how moving to a public cloud datacenter would drastically change things would be in the area of network communication. Taking Amazon AWS for instance, there is no concept of VLANs. The customer simply gets presented with an overlay network with native tools on top of a purely layer 3 network. So, you aren’t relying on VLANs for segmentation.

In the public cloud network, the network policy is host centric and not at the network level. The enforcement happens at the host level via security groups. Also, with Amazon the size of the network is fixed once you provision the VPC. So making sure you provision the correct size for your VPC network is critical on the frontend and is a good example of how planning the migration to the public cloud would need to be thought through carefully.

With private datacenter migrations, we could basically create a one for one scenario of infrastructure in the target datacenter and use a “cookie cutter” approach to provisioning resources in the target datacenter as they exist in the current production datacenter.

Planning Time

Generally speaking, a datacenter migration is a major undertaking that should not be underestimated in importance to completing successfully. A botched datacenter migration could potentially result in service interruption, data loss, unhappy customers, brand reputation damage, and ultimately real damage to an organization that was lax in proper planning and preparation of the process.

With the above stated, planning for a datacenter migration shouldn’t happen in the span of a day or two. There may be weeks if not months of preparation. What would be included in the prep work to get ready for a datacenter migration?

  • Site survey of the existing datacenter and the new datacenter – One of the necessary items that needs to be done is a site survey of both the existing datacenter and the new datacenter. Are the existing physical resources in the current datacenter going to be moved? If so is cabling and other physical Layer 1 connectivity fully understood so this can be replicated in the target datacenter once the physical infrastructure is moved? If the physical resources are not being moved to the new datacenter, have adequate replacements for the existing infrastructure been provisioned?
  • Documenting everything – Are all the infrastructure requirements including storage, compute, network requirements, application requirements, and any other infrastructure requirements documented?
    • Too much documentation is better than not enough documentation
    • Make sure every rack, “U” of the rack, virtual machine, network, and application is documented whether considered important or not
  • Dependencies – Is it fully understood what dependencies exist in the current datacenter environment that need to be replicated in the target datacenter? Are there current ancillary systems in the current datacenter that need to be replicated in the target datacenter?
  • Network needs – What are the LAN and WAN considerations that need to be made for existing applications in the current datacenter that need to be considered for the new datacenter?

    Private Datacenter:

    • VLANs – Are there VLANs that need to be provisioned in the new datacenter that are currently used in the existing datacenter
    • IP Addressing – What are the IP addressing needs of resources and applications in the current datacenter?
    • Do legacy applications rely on any hard-coded IP addresses that need to be flushed out before making the move to the new datacenter?
    • What are the WAN IP address concerns? Have all WAN IP address considerations been taken into account?
    • How will DNS and name resolution happen?
      • Will resources in the current datacenter and the new datacenter run in parallel allowing for shifting DNS gracefully allowing time for DNS convergence?
      • Will other mechanisms such as IP Anycast be used to advertise the same IP prefix from multiple locations and allow BGP or other routing protocols to route based on the costs and health of the links?
    • Have the necessary WAN circuits been ordered so that sufficient lead time is allowed to turn up the new circuits? Some ISPs may take as long as 90 days to turn up a new circuit. These time allowances should be built into any datacenter migration plan.

    Public Cloud:

    • Since VLANs do not exist in public cloud, any layer 2 requirements would need to be thought through in reengineering network access
    • How many IP addresses do you need? What size does the subnet need to be? AWS defaults to /16 subnet
    • How does network security need to be setup? What security groups need to be taken into consideration?
    • 500 Security group limitation per VPC – Will your network require more security groups than are provided?
    • Will you need to provision multiple VPCs?
    • If moving to public cloud, most likely there will need to be automation tooling changes. Have these been considered?

Go Through a Mock Run of the Migration

While you may not be able to go through an entire nuts and bolts run of the process of the migration, having one or several test runs of the migration can be helpful. If you are also able to stage key components such as network transition items within a lab environment, this can help shed light on potential issues with applications, etc., before the actual migration takes place.

  • Talk through major points of the migration with key members of the team.
  • Know the order of events that need to be executed as most likely there will be some items that will require other items on the check list to be completed first.
  • Utilize lab environments to simulate the data center migration including network resources as well as application testing and troubleshooting.

Execution of the Data Center Migration

After all the planning has been done and resources are ready to turn up at the new datacenter location or the public cloud, it is time to execute the move. Considerations during the move:

  • Know who is responsible for which aspects of the move. The last thing you want to happen is for assumptions to be made and responsibilities for crucial aspects of the move to fall through the cracks.
  • Create a detailed action plan with everyone involved with the migration project. List out responsibilities.
  • Have contact information of everyone involved, phone numbers etc., so that time is not wasted trying to find contact information instead of working on potential issues that may arise.
  • Have additional vendor contacts on standby. This would include datacenter contacts, ISPs, network engineers, infrastructure engineers, ops engineers, etc.
  • Inform end users ahead of time either via electronic communications, banner page, etc. Be detailed in the maintenance window that should be expected as this will minimize the frustration of end users.
  • Have a team ready for triage in case of an influx of end user issues as a result of the resource migration.

Post Datacenter migration

Once the datacenter resources have been migrated, we need to quickly gauge any issues with performance or any other system issues as a result of the migration.

  • Have a team assigned to this task either via manual checks or automated means to validate the integrity of system processes and application availability after the migration.
  • If you receive traffic from various parts of the world, simulate traffic coming from different end points around the world so that you can test any discrepancies between geographic locations that may be caused by DNS convergence if name records have been changed.
  • Test not only for errors in applications, but also the performance of those applications.
  • If you expect performance improvements, have those improvements been realized?
  • Is performance worse, indicating an underlying issue with the migration?
  • Notify end users when the maintenance period is over and the system is expected to be performing normally. This will help end users to know if they may be experiencing a migration related issue or a real problem.
  • Have a post mortem with all team members involved to collect any issues that were encountered during the datacenter migration. This will help build a stronger team in the future and bring to light any issues that could have been prevented and take those into future projects.


Datacenter migrations can potentially be one of the most complicated processes that an organization may have to undertake. It involves very precise and calculated changes to be made to systems so that those systems can either remain online during the migration or be back online as soon as possible. The rewards of a successful migration can be tremendous. It can allow a business to grow its technology needs into a more modern and technologically advanced datacenter. Additionally, it can allow an organization to transition to the public cloud for housing resources. Either way, proper planning, testing, and execution of well thought out plans will allow an organization to pull off the challenging feat of a successful datacenter migration.