Data Center Migration Rules
Well defined and potentially repeatable processes define successful data center migrations. Planning the migration is perhaps the most time consuming portion of the project, and for good reason. It defines the ‘foundation’ that the success of the migration will rest on – the repeatable (if so desired) plan and underlying processes that will carry the project from kickoff to completion.
You will likely have a lot of questions when researching and planning for your specific migration. Many of the answers will, too, be specific to your particular situation. There are some rules and guidelines, however, that are quite universal in nature and can apply to most migrations, while conversely there are certain “do-not-do’s” that apply almost universally as well. And just like we’ve all gone to the beach and forgot the towels or the sunblock, sometimes the more obvious things are the easiest to overlook.
The following list of data center migration rules highlight some of the more universal “to-do’s” and things to keep in mind while undertaking the planning of a migration. Without further ado, thirteen data center migration rules to remember when planning your migration:
1 – Ensure you know all the details of exactly what you (currently) have. — Estimates won’t cut it when migrating. To plan a successful move, you need to know all the details about everything you have running in your current data center. You need to know how many workloads are physical, how many are already virtual, how many utilize local storage and how many rely on shared storage – and then you must decide how many are going to work the same way once moved, and how many workloads will be handled differently (e.g. p2v’d, moved to shared storage, etc.) in the new environment to correctly calculate the new infrastructure purchases and costs.
2 – Understand your data center’s interdependencies – A detailed asset analysis and a complete map of applications is a must for planning any data center migration. All the details need be included, from the simple things like redundant power supplies being connected to a single UPS to multiple applications relying on two copies of a database living on a single shared storage array, understanding dependencies at all levels is very important to a successful move. If the UPS in question were to go down before one of the power supplies was relocated to a separate power source … outage! If the storage hosting both copies of the ‘redundant’ database were taken down for maintenance … outage! A complete, accurate, up-to-date application dependency map is a must when planning a migration.
3 – Write procedures in concise, step by step detail – Judgements can lapse and mistakes can be made when the early hours of morning roll around during the course of a long move. A detailed, step by step procedure that includes everything right down to the necessary commands to run will prove key to the success of a long move. Thorough planning can be the difference that allows a move to succeed.
4 – Ensure leadership is clear for all phases of the project — Decision makers and gatekeepers need to be clearly identified, and their responsibilities clearly laid out as well. Someone must have overall responsibility for the move, while someone must handle communicating with leadership. Gatekeepers both need to sign off on completion of phases of the migration, and also have the authority to enact a backout.
5 – Err on the side of overestimating the amount of time you’ll need to migrate – In mathematical best case scenarios, a transfer of 10GB of data over a 10gbps link should take ~8 seconds; that, however, assumes 100% dedication of the link’s bandwidth for the transfer in question, and that the transferring protocol has no overhead with 100% efficiency. There is always, overhead, and the likelihood of a link having no other traffic is slim to none if it isn’t isolated and dedicated to the transfer at hand.
Staff too tire as migrations progress, and the time it takes to fill and cable one rack’s worth of equipment may be a lot less than the time required for the same staff to rack and cable the 10th rack. Budget extra time to allow for variations in things that are outside of your control. Small overestimates and cushions allow for a bit of the unexpected without hindering success.
6 – Create a thorough test plan – A test plan should detail out the milestones of success, validation criteria, as well as who will perform the validation. A thorough test plan helps avoid the “blame game”, and when staff return to work, all applications will have been tested to be available and performing within acceptable ranges.
7 – Create a detailed back out procedure. A backout plan should be incorporated as *part of* the very same plan that will be used during the migration. It may seem like a lot of extra work, but if it does become necessary to back out, both the staff performing the work and executives will be extremely grateful to have it. The plan should specifically detail what sorts of failures would put the back out plan in motion, and exactly who is designated to make the call to put the back out plan into motion.
8 – Ensure communication channels are designated, open, and utilized – The quality of a migrations communication can affect success in many ways. Communication can prevent the premature execution of steps before other team members are ready, while not communicating completion can result in others waiting around, needlessly lengthening the migration. Creating a migration dashboard and associated control center to keep tabs on progress and communicating with users are all important, as well.
9 – Be extremely attentive when ordering hardware for a migration. Not only can mistakes like the wrong server form factor or even simply the wrong rail kits really mess up a migration, but these mistakes can also be extremely costly to correct, even if caught with sufficient time to remedy them. The time and cost involved in repackaging, addressing, reloading, and shipping back hundreds of servers, switches, or rail kits can put a real dent in the perceived success of a migration — before it’s even begun!
10 – Verify the engineering aspects of your target location – A trial run to ensure any large equipment will clear tight corners or narrow openings or hallways is a good idea. The same goes for elevators — Can your equipment fit into them, and can they handle the weight of all of the equipment you are planning to move? If not, you might need a crane, and that might mean removing windows, closing streets, etc. It is also important to ensure that the building itself can handle the weight of all the equipment you are bringing in. A structural engineer can verify this for you and should be brought in if there is any question
11 – Verify Power Availability – Full racks use a lot of power. Modern hardware has fit more and more compute power into smaller packages, and coupled with larger 55u racks mean your installation might need more power per square foot than many data centers were originally designed with. Running power vs. bootstrap (startup) power must also be considered. Power draw at startup is often an order of magnitude greater than power consumed while running or at idle (sometimes as high, or higher than full load draw!), so equipment must be configured to power up in batches that stay within the power envelope and avoid overloading a circuit.
12 – Verify cooling availability – The ability to keep your equipment cool is as important as the ability to power it all up. Cooling availability needs to be at the forefront of thought while planning a migration. Underestimating cooling needs could result in forced power downs of hardware to lessen cooling loads, and can even halt a migration in its tracks until larger units can be installed, if they can be at all…!
13 – Plan the fate of hardware from the old data center – Hardware disposal can be costly. There are companies that specialize in disposal, handling the strict requirements for handling sensitive data. If the hardware isn’t that old and doesn’t contain data that requires it be destroyed, reselling it can allow for some cost recuperation. The market for used hardware is very large, with for example, Dell operating an entire line of business that focuses solely on used and refurbished hardware. Ensure you’ve planned for the hardware’s end of life, regardless of which disposal options apply; otherwise, you’ll be stuck paying data center rates for storage!
