Service Express acquires Mid-Range. Read the press release for more.

Read Now
Two Professionals Talking, Holding Laptop

Articles & Insights • 8 min read

How To Plan A Successful Data Centre Relocation

Before Relocating Your Data Centre:

“Where is your project plan?” You need to start creating a project plan once the decision to relocate is made. There are many critical details to address and steps to track within a project of this scope. Knowing your status at each step of your project plan and preparing a back-out plan well in advance of your relocation is essential.

How do you start?

Relocation or Migration?

A data centre relocation means physically moving your current data centre equipment to a new location: either a different room within the current building or a new physical address. At this initial stage of the move, you will need to evaluate your future footprint by size, spacing, ventilation and power load capabilities. Ask yourself what will be different at the new location. Identify what additional cabling and/or network equipment may be needed. You will need to coordinate proper shutdown and de-installation, shipping preparation and installation and create a thorough testing plan.

What are your insurance options? You may be in a position to self-insure. If not, consider a rider to your existing insurance to cover the value of the equipment being moved. In some cases, vendor insurance may be available; however, it is relatively expensive. The insurance offered by the mover is typically not a good choice.

Careful planning of a relocation minimises the risk of software and hardware failures during transit and failures due to improper re-cabling. Paying attention to details such as time zones, arranging for escort badges in advance, taking the extra time to reconfirm the schedule with the delivery lorry time frame, reconfirming that all technicians involved have reviewed and understand the project plan and covering all safety concerns will contribute to smoother execution and a successful move.

If your strategy includes purchasing or leasing similar servers for a new data centre, a migration may be preferred. A migration is the process of transferring data between computer systems or between storage devices (regardless of location). A migration minimises downtime for environments with strict SLAs and provides a quick, reliable back-out should the migration fail. Keeping your existing data centre running can provide you with a staging or disaster recovery site and a migration gives you off-line time to build and test the new environment.

Creating a Project Plan

A project plan is a must-have. Here are our key suggestions:

  • Assign a Project Manager: This person holds weekly meetings to confirm the progress of the plan and the accomplishment of tasks in a timely fashion.
  • Identify Prerequisites: These details are very important and, if not considered early, can lead to delays during the relocation. Possible show-stoppers include failure to confirm the appointment with the delivery lorry, no pre-approved access for vendors, lack of sufficient space, unidentified power and temperature requirements or the lack of remote console access in both the old and new data centres. See additional software and hardware prerequisites listed on Prerequisites: Environment, Hardware & Software.
  • Create a List of Resources & Dates: Instead of listing responsible departments, list names of individuals who are assigned a relocation task and include a completion date. Holding each team member responsible for providing a status at every meeting results in better adherence to the schedule.

Sample Project Plan for Relocation

For: 22 Servers, 4 Storage Devices and 3 Network Switches

* Find our complete Data Centre Relocation Checklist here.

How to Plan a Successful Data Centre Relocation Checklist | Service Express

Prerequisites: Environment, Hardware & Software

Order spare hard drives and CPU/memory or have your hardware support vendor onsite with parts and a commitment on how soon additional parts can arrive onsite if needed.

Be prepared with spare media for installation (operating system boot DVDs, application media and licences) for the worst-case scenario.

Confirm levels of software and hardware support on each piece of equipment.

Involve your network team: This team is crucial to the relocation and they must have network switches preconfigured. Patch panels in the new data centre should be tested in advance for both network and storage.

Confirm that the power at the destination is cabled properly with the correct connectors and verify that the network connectivity/availability is working.

Ensure adequate power is available and has been tested.

Ensure sufficient space and ventilation are available for racking
servers.

Hardware Move Checklist – include in the project plan prerequisites and prepare a workaround for problems that could arise during the hardware relocation.

  1. Is there a loading dock? Is there sufficient height to move the equipment in or out?
  2. Is a lift gate lorry required to access the shipping/receiving dock?
  3. What will be used to move the equipment to the loading dock?
  4. Will the equipment fit in the lift?
  5. Is there a restriction on the lorry’s distance from the building?
  6. Will there be a forklift and operator available?
  7. Is there an area for packing and unpacking in both data centres?
  8. Which equipment should be moved first/last? Identify development, staging and production equipment.
  9. Will equipment need to be un-racked and racked at the new location?
  10. Will you or a vendor perform cabling work?

Prerequisites: Project Plan Tasks

It’s almost time to go and the task list below should be included in your project plan.

  1. Conference call number is scheduled in advance. You have contact info for each participating member of the move, including vendors and a management escalation list.
  2. Review each step of the detailed project plan. Each task is assigned to an individual with an expected time frame to complete. If completion tasks are running behind, you are able to calculate the remaining time required and can decide whether to go past the maintenance window or to back out.
  3. Confirm all administrators have arrived or are online.
  4. Confirm backups are successfully completed.
  5. Disable monitoring of the servers before they are shut down to avoid page notifications which can lead to confusion early in the migration.
  6. DBAs and application administrators start by disabling services.
  7. OS, storage and network administrators shut down and power off servers. The OS admins may choose to reconfigure networks for the new locations before powering down, but this should already be part of the original plan.
  8. New cabling in the new data centre should already be labelled at this point.
  9. Network administrators will check cabling, switch configuration and firewall connectivity. This check is critical because if there is a difference in a switch port configuration from the original environment, a server may not be able to communicate on the network. Check in advance to avoid any unnecessary server trouble.
  10. External devices (such as storage arrays) are usually powered on first before servers so the storage will be visible to the server after the first boot-up.
  11. The OS administrator will remotely connect to console access to reconfigure network settings for the servers (if this was not done prior to shut down).
  12. After a successful power on, the OS administrator will check the health of the OS, network and storage connectivity. Then the DBAs and application administrators will check services.
  13. Your QA team should test all applications from the front end to the back end and certify the environment before notifying users that the environment is up and functional.
  14. Final steps will include a back-out strategy similar to the steps above. This is an extremely helpful resource in the unlikely case that you must move servers back to the original site.

Backups

We all know that backups should be done and are certain that they are being routinely performed, but have you ever tested them? If not, the time to test is now, not after powering the server up in the new location and discovering the last good mirror in your volume group is bad. Hopefully, you currently have a development, QA or staging environment that closely resembles your production environment where you can test recovery. If this is not the case, you need to delay the relocation and test your backups.

Key items to remember:

OS dumps unique to each OS are critical to restore an OS properly (e.g. ufsdump for Solaris, make_tape_recovery for HPUX, mksysb for AIX).

Your data for database (DB) and other applications are most likely on external storage arrays and are being backed up by tape for off-site purposes. Do you have a Disaster Recovery (DR) site with this data being replicated by a storage array or cluster product? Regardless, know and test how you would restore the data in the new data centre should things go awry.

Be ready with media and licence keys for installing backup server client software if needed. This would be the second step after an OS install recovery and a prerequisite for restoring the application data.

Ensure that your backup and build servers are ready to go in the new data centre prior to the relocation date. This is optional, but important should you immediately need to perform a recovery after the physical servers are moved.

Upgrading Hardware in Parallel

The relocation is a considerable endeavour in itself and you do not want to compound the factors of the move with a software upgrade. If there are any unexpected issues to address after the relocation, you do not want to double your troubleshooting efforts with any upgrade complexities. A hardware upgrade can be the exception, especially if you are purchasing new equipment, but even then, you are introducing extra risks. It pays to be cautious, rather than bold, in the case of a relocation.

As tempting as it may be to utilise your maintenance window to take advantage of upgrading your OS or applications during a relocation, DO NOT.

Additional resources