This post was written for, and originally seen on, ColoandCloud.com.
Data Center migrations are not something anyone should take for granted. A poorly planned and/or executed migration can have lasting impacts, including: unexpected downtime, interruption to revenue, and customer satisfaction losses.
With corporate data centers and co-location facilities housing the life blood of corporations, impact isn’t limited to a single company or department anymore. Hosted applications, customer portals, ticketing systems, etc are all impacted by even the smallest outage, let alone an unexpected increase in outage window due to poor planning! Migration plans need to include provisions for all affected parties, including customers, vendors, contractors, developers, scheduled reports, auto-support log transmissions (both incoming and outgoing), internal departments, etc. There is nothing worse than a customer not being able to contact your support group because your exchange server, ticketing system and phone system are all on a truck simultaneously. …let’s not even consider the ramifications if that truck crashed!
As you can clearly see, all it takes is one bad planning decision and it can have all kinds of lasting impacts on your business.
When the decision to move a datacenter is made, every facet of not only your data center environment, but your overall IT strategy must be clearly understood prior to starting the planning phase of the project. So, before you begin the data center migration planning process, you need answer a handful of very important questions regarding your upcoming move.
The first question that must be answered is “Why are we moving our datacenter?” Many factors can precipitate the need for a data center migration – growth beyond current capacities, hosting provider performance, real estate changes, local data center economics, density requirements, staffing considerations, green initiatives, etc. While all of these factors are valid and common reasons to move a data center, understanding the driving force behind your decision will guide the migration project plan.
The next question to answer is “Where are we moving our data center?” This is a multi-part question; one that has lasting impacts in a lot of areas. Are you moving to a corporate owned and maintained facility, or are you moving to a co-lo? Does the new facility have the appropriate bandwidth providers on-net already, or do you need to have fiber run into the building? These types of questions are good to get out of the way early in planning. If you need to dig up a freeway to get fiber to your building, that may take some time…
“When are we moving?” Are you planning a move several quarters or years from now? If a full site build is required, you may begin your pre-move planning years in advance, or as I have experienced more than a few times, is your move literally this weekend? Both scenario’s above have benefits and drawbacks, a long planning phase may root out issues you may miss in a faster paced migration, but the state of constant change in the data center may render your equipment list and move plan extinct several times during planning. I am an advocate for “as much notice as possible, within reason…” I know things change. Move specifications change up until 3 days after we are done with a move in many cases. Things that were on the list drop off, (“Backups are still running on machine 7, so we need to move that to the next move phase”) and they also jump on the list at the last minute, (“if you can grab box 47 as well, you will make my boss and my developer very happy…”). It happens…plan for it. Which leads me to…
“What are we going to move, and what is *not* moving?” This is a fantastic question, and one that gets answered in vague and uncertain terms in almost all cases. Many people try to upgrade hardware as part of a data center migration plan, and in theory it is a great idea. Why move stuff that is 4, 5, 6, …10 years old when you have the opportunity to scrap that stuff and build on new and efficient technology?
Legacy Apps. That’s why you shouldn’t scrap things until after a migration is complete and tested. “Legacy apps” are things that were put on a server with little or no documentation, by someone that is no longer at the company, but are responsible for critical tasks. I’ve seen things from primary DNS missing, financial reporting no longer working, backups failing, all sorts of things all because of “legacy apps” whos hardware was on the scrap list during a migration. Data Center migrations are complex enough, there is no need to introduce additional complexity. Unless you KNOW the hardware is dead, at least move it, cable it and wait to power it on…if everything comes up, then you are in the clear, scrap it. But if something critical is missing or broken, you have some level of recourse.
“Who is responsible for…” In my experience, this question is almost never answered until move day, and if it is answered before move day, the wrong resources are often assigned to the move tasks. In a move plan for one of the very first migrations I ever worked on personally, the only network engineer was tasked with racking and cabling 50 devices before he could start configuring the network for the new IP range the company got in their new facility. The unfortunate part of this story is that by the time that one guy finished racking and cabling 50 devices, he was exhausted and the network configuration, turn up and testing took 15 hours longer than planned. If another resource was tasked (or resources more appropriately) with the racking and cabling tasks, the lone network engineer could have arrived later in the move phases, and been fresh and ready for his primary function of configuration, turn up and testing the network. 15 hours is a long time to extend an outage window, especially when it was easily avoidable.
“How” you are going to move your data center is often a heated debate. Of course, with unlimited funds, no time limit and unlimited staffing resources you can move however you would like! However, here in the real world, it comes down to speed, efficiency and cost. There are countless ways to migrate, many with little or no downtime. Products like vMotion make it easy to stand up a new VMWare server and logically migrate virtual servers with no downtime. Fully redundant environments make it easy to migrate physical systems with no downtime. Multi-phase migration plans can minimize impact to your customer base, both internal and external. How you move is up to you. My advice, consult the professionals. There are people that specialize in moving data centers (I know…I’m one of them!) the insight they can provide is invaluable.
Did I miss anything? How did your data center migration go? Was it on time and under budget? What advice would you give someone trying to plan a data center move? Let us know in the comments!!
Data Center Blog - Data Center Migration Experts
I love when I get positive feedback, and I love it more when it comes from a new customer!!
It’s not quite as exciting as 
lately between Greenpeace and Facebook, Yahoo is opening a new data center using their patent-pending Chicken Coop design.
