So, you’ve decided to finally take the plunge and move your data center to a new location. If that’s the case, the first thing you need to do is come up with a detailed project plan. That way, you’ll be able to track the progress of the entire effort, as well as of individual steps, to make sure it all goes smoothly and without unwanted improvisations.
The first thing you need to ask yourself is “Do I really need to relocate, or migrate?”
Relocating a data center means moving all of the existing gear to a new physical location, be that a new room within your premises, or somewhere else, entirely. If indeed you are looking to relocate, make sure to double-check the future premises for size, spacing, as well as how well ventilated the room is, and how much power the infrastructure can consume.
The best way to go about it is to try and compare the new location with the current one, and look for changes. Make sure to pay attention to cables, or network gear. Will you be needing additional cablework? Also, make sure to properly coordinate the data center’s shutdown, de-installation, packaging, shipping, and then everything - in reverse.
After that, make sure to analyze your insurance options. Some companies do it in-house. Others may start by double-checking if their current insurance covers the value of the gear they’re relocating. Properly solving insurance is an important step, as otherwise it can turn into a lose-lose situation: while vendor insurance could be too expensive, mover insurance is usually subpar in terms of costs covered and quality of service.
By planning the relocation ahead, businesses minimize the chance of both software, or hardware, going awry. In many cases, things go south during re-cabling and reconnecting various gear. Make sure to keep in mind things such as time zones, escort badges, as well as delivery timeframes. The technicians need to be well acquainted with the project plan, and need to keep all safety concerns in mind. Only then can you know that the relocation will be a seamless, smoothly executed project.
On the other hand, if you’re considering purchasing, or leasing, new servers for the new data center, then migrating may actually be a better solution than relocating. Unlike relocation, migration only moves the data between computer systems and storage devices. Its main advantage is the minimum downtime it requires, especially for environments with solid service-level agreements (SLA), and the fact that a failed migration incurs minimal costs. By keeping your existing data center operational during the migration, the organization can take the time to properly set up the new data center, prepare for any potential disasters, and test the new premises.
Now that you know the importance of a project plan, here’s what we suggest you do:
When it comes to hardware, always make sure to have spare parts. That can include hard drives, processors, or memory units. If you can’t have them on site in advance, make sure to have your vendor at hand, and ready to supply necessary parts with the highest priority.
In terms of software, bring everything: operating system boot drives, application media, necessary licenses. All these things will prepare you in case things go sideways, and ensure that the time needed to remedy a problem is minimal.
Ensure you have the proper support, for both hardware and software, for each piece of gear you’re moving.
Make sure the network team is on board. The network team is pivotal to the relocation, as they need to reconfigure all network switches. The team should also make sure to test, in advance, all network, and storage, patch panels, for the new data center.
Ensure the quality of the power grid. This is absolutely crucial. The new location needs to be properly cabled, supplied with all the right connectors, and tested that all works as intended.
Physical space and air flow. Make sure the new location has enough room to accommodate all of the gear, and that the room is properly ventilated for racked servers.
Steps checklist. The plan needs to list all of the essentials, and have a backup solution ready for every step of the way, in case something does not go according to initial plan. There should be no improvisation once the migration is kicked off.
Does the new location have a loading dock?
Is the entrance high enough for trucks to go in and out without problems?
Will you be in need of a lift gate truck to access the shipping dock?
What about moving the gear to the loading dock? Any surprises there?
Is there an elevator? Can the gear fit in there?
How close can a truck approach the building?
Will you need a forklift, and will it have an operator on standby?
Is there a specific zone where the gear needs to be packaged and un-packaged?
Are there any rules on which gear needs to be moved first?
Does the gear need to be un-racked at your current location, and then racked again, at the destination?
Who will connect the cables on the new premises, the company, or the vendor?
You’re almost done. Now, all you need is a task list such as the one below:
Set up a number for a conference call, where you will gather vendors, managers, and everyone else participating in the migration/relocation.
Go through all off your plan’s steps, make sure there is an assignee for every step, and that deadlines are in place. That will help you plan the time needed for the entire project, and help you understand whether or not you’ll lag behind. In both cases, knowing your timeframe in advance will help you prepare for future moves.
Ensure all admins are accounted for.
Ensure all data is backed up.
Before shutting servers down, disable monitoring to avoid getting unnecessary and confusing notifications.
Have database and application admins start with disabling services, first.
Have operating system, storage, and network admins, turn off all of the servers. If operating system admins want to reconfigure the network for the new location before shutdown, make sure it’s all listed in the plan.
Make sure cabling in the new data center is properly labeled.
It is paramount to check, then doublecheck, the cabling, as a difference in a switch port configuration could result in failed communication between the server and the network.
First power up external devices such as storage arrays, to make them properly visible when the OS boots.
Have the administrator remotely connect to console access, in order to reconfigure network settings for the servers.
Following the boot-up, make sure the operating system admin analyzes the health of both the operating system and the network, as well as any storage connectivity. After that, database and app admins can check services.
Make sure your quality assurance team tests all applications from both the front end and the back end, to make sure the environment is operational, before sending out the notification to your users.
To complete the process, make sure to create a back-out strategy, akin to the list above.
The importance of regular backups is known, and well-documented, but one of the main reasons why many businesses end up not using their backups is because they turn out to be corrupted. This is easily avoidable by regularly testing the backups to make sure they are working as intended.
That being said, make sure to test your backups well in advance, because if you do it after booting up the servers, it might be too late.
To restore an operating system, pay attention to unique OS dumps. Having database and app data on external storage arrays, and having tape backups off-site is standard practice. But do you have a Disaster Recovery (DR) location, where you replicate your data? The point is - you need to know the exact process of data restoration, should something go south.
After recovery-installing the operating system, make sure you have both media and license keys needed for server client software installation on hand. Also, before relocating, make sure both backup and build servers are ready to go. While this step isn’t mandatory, it will come in handy if you need to recover any data.
Relocation is probably the worst possible time to be doing any software upgrades. There are enough unknown variables as it is, and enough things that can go wrong, to complicate things further with software upgrades. However, hardware is a different story, particularly if you’re bringing in brand new gear. Still, there are risks involved, so make sure you’re extra careful.