The who, what, where and whys of data centre migration

September 17, 2018

Data centre migration – an ongoing trend that doesn’t look like it’s going anywhere any time soon.

Many people do it. Sometimes it goes smoothly, sometimes it doesn’t, as unforeseen challenges are often uncovered along the way.

So, what does it take to succeed? Our guide to the who, what, where and whys of data centre migration will get you up to speed, if you’re not already.

Why?

Firstly, there are several reasons why organisations would want or need to migrate or transition a workload/s.

Workload/s are running on a failing end-of-life physical server and need migrating to a fresh new supported physical. This is known as a P-P (Physical to Physical) Migration.
An organisation is moving towards a more fully virtualised platform and wishes to consolidate its physical estate. Also called a P-V.
The workload is already virtualised but you wish to move it either onto another virtual environment, possibly in a different data centre or a different flavour of virtual platform. Referred to as a V-V.
Or, what’s becoming more common, is organisations are deciding to move already virtualised workloads out to the cloud, a V-C. But to be honest, this isn’t really any different from a V-V, as the workload is already virtual and remains so, just in another format.
To create a more automated system, allowing their IT teams to focus more heavily on innovation, rather than tedious, everyday operations.

Who, what, where?

Due-Diligence Phase

Our first step, and by far the most time-consuming chapter in data centre migration, the due-diligence phase is certainly where most of the work gets done. De-risking the moves and ensuring service isn’t impacted often takes up to 70-80% of the overall migration timeline. While identifying all of the workload owners, drafting a server list of all your hosts and recording any glaring warning signs are also all an important part of the process.

The Planning Phase

Once the possible red flags have been identified and it’s clear what’s actually being migrated, it’s time to mitigate them. After that, drafting a plan for the migrations, including grouping the workloads into services, estimating the overall project duration, pinpointing what support staff you’ll need during each migration and establishing a running order will need to take place too.

Preparing the Destination Environment

The preparation phase is pretty similar, regardless of the end point. So, some things to consider in your destination/target environment are: network requirements, ports, routing and VLANs, IP’s, storage/data store preparation, backup requirements, monitoring and tooling and redundancy and resilience.

Pre-Migration Steps

Sometimes, the most obvious things slip past our radars, and as simple as these almost day-to-day steps may seem, they play a key role in any successful migration.

Make sure you:

Check backups are available and tested prior to migration.
Disable any antivirus/security tools you have running as they will always throw up issues.
Shutdown any active services on the host.
Do some housekeeping such as cleaning out temp files.
Have a roll back plan for every service.

The Migration

Going about the actual migrations depends heavily on the old hosts, services platformed on them and the destination, so here are some options:

Well Known Migration tools:

VMware vCentre Converter will convert just about any physical or third-party image format into a VM. Once virtual that VM can be moved anywhere internal to that platform using vMotion.

Exporting out to AWS from VMware you can use the available import export tools from AWS , if not already using VMware vRealize is.

If migrating to MS AZURE, then they don’t call it a migration tool but MS Site Recovery V can be used to replicate your workloads into an AZURE environment.

If all else fails, a simple backup and restore into the new environment is possible, but is a time-consuming method.

Post Migration

Once everything’s sorted, it’s time to:

Install any new tools and monitoring in your new environment and ensure the correct alerts are going out to the right support teams.
Update/Remove any old device drivers, especially if you’ve gone from a P to a VM.
Check the event logs again to ensure there are no errors following the migration.
Test network connectivity.
In your earlier engagement with the applications and service owners you will know who you need to then conduct UAT and sign off before handing over.
Update your support documentation.
Decom your old physical estate, but it’s worth keeping it for a short time, just in case.

At Q Associates, we understand that every client environment is completely different and needs its own strategy. And that’s where our technical team’s expertise comes in. With over thirty years of migration experience under our belt, a flexible, round-the-clock active support service and our customers’ best interests always at the forefront, why not speak with one of our consultants to find out more?