Migrating between data centres, or even from your office into a data centre for the first time, is a complex process that is often left to the last minute and not thoroughly planned. In the first of a short series of articles we look at the five main areas that you need to consider when planning a move.

1. Things you’ve forgotten
Before you even start looking at the logistics of moving your equipment you need to perform a full audit of what you have, how it works and the configurations running on each machine. Even if you have documentation from when it went live, things will have changed. And the longer it’s been in place, the more ‘hacks’ and workarounds that will have been applied as your application has matured.

It’s never too early to start a detailed audit of your equipment, configurations and applications. Everything ought to have someone who is responsible for it, and if there isn’t an owner you need to ask yourself if you still need it.

Once completed (and I’d recommend doing this even if you’re not migrating to a new data centre), the audit needs to be stored in a management database that can be accessed by multiple people to facilitate maintenance. This could be an online service like Google Docs, but before storing your sensitive audit online you would need to look at the information security implications of storing this data in a cloud environment. But whatever you do, don’t store it in a spreadsheet on one person’s laptop, as it will likely get lost or corrupted very quickly!

2. Planning post-migration testing
Testing is always a challenge and post-migration especially so. However, a well thought out plan will save you a lot of headaches, as well as providing solid evidence of your applications’ performance to offer to end-users if they think things are running slow or acting oddly after the migration.

Once you have designed your testing schedule (this could include tests such as average page load time, CPU usage, latency or any other metric that can be measured), you should perform the tests on your equipment and applications before you do any migration work. Like any good tests, you need a baseline so you can tell how things have actually changed, rather than how people think they have changed.

Enlist your staff, and possibly users, to perform the tests. Document the results and then repeat after the migration; you are looking for the changes or deltas between the two to tell you whether the migration has been successful or not.

3. Managing staff and informing users
Unless you have the resources to provision a completely new environment and to run your applications in parallel during a move, then the actual physical shifting will almost always take place during unsociable hours.

The migration schedule, including informing everyone involved (from staff to users), will take months so make sure you start on it early. Managers will need to work out, and budget for, overtime and you may find the planned date needs to be rescheduled several times due to users’ objections.

4. Application delivery
Application delivery optimisation (ADO) is fragile. If you use load balancers or WAN optimisers (two different ADO technologies) you’ll have to peel back the layers of their configurations and understand how you are going to manage the migrations. You may find that this will require additional investment for duplicate hardware, or dedicated connectivity to connect the old site to the new.

While you are reviewing the ADO devices, ensure you look for changes that you can make in their current configurations that will give you greater modularity for the future.

5. Hidden configuration
Lastly, somewhere within all your applications and databases you will find a hardwired IP address or domain name that has been happily sitting there for years. These are often overlooked in the rush to plan a migration and can take hours to find once you realise an application doesn’t work.

Not only should you start replacing these as soon as possible with dynamic links that you can update centrally, but you can also take this opportunity to make sure your applications are fully IPv6-compatible. Of course that means you need to have an IPv6 strategy worked out, so you can use it as a reference during the application and network component review.

Follow this approach and you are well on the way to a successful migration of your hardware and systems to the data centre.

In part two we will look at the pros and cons of keeping your existing infrastructure as a backup for disaster recovery.

Posted by David Barker, founder and technical director at green colocation and connectivity supplier, 4D Data Centres.
You can also David’s company on Twitter @4DDataCentres.