20 Data Center Migration Mistakes

1. 20 Data Center Migration Mistakes To Avoid www.device42.com Original Article: Top 20 Data Center Migration Mistakes to Avoid

2. 1. Lacking a complete infrastructure assessment / not knowing what you have • To plan and execute a move successfully, you must first know all the details about everything you currently have running in your current data center. • You need to know things like: • How many workloads are physical, how many are already virtual. • How many are using local storage. • How many rely on shared storage. • Then you must decide: • How many are going to work the same way once moved. • How many workloads will be handled differently in the new environment to correctly calculate the new infrastructure purchases and costs. www.device42.com

3. 2.UnclearLeadership • A project manager is a “necessity” not a nice-to-have. His task would be: • Overall responsibility for the move. • Authorizing next steps to take place. • Communicating with leadership about progress. • If necessary, calling for a cancellation and backing out changes if all else fails. • “If the right person gets the • authority to make decisions, extra unnecessary and costly downtime can be avoided”. www.device42.com

4. 3. Not recognizing dependencies A complete and up-to-date application dependency map is an “absolute must” when planning a successful data center move. “Understanding dependencies at all levels is extremely important to planning a successful move. If that UPS were taken down before one of the power supplies were moved to a separate power source, the server would fail; and if the database in question were taken down along with the single application that staff initially thought was utilizing it, other application failures would follow “. www.device42.com

5. 4 . Not writing a step by step procedure • A step by step procedure detailing exactly what to do next, including commands, and definitions of what constitutes success is a key to the success of a long move. • Good, thorough, and detailed pre-planning that includes necessary steps and commands spares tired staff having to make (bad) decisions, allows a move that might otherwise fail to continue through to success. • 20% pay rise www.device42.com

6. 5.Not verifying equipment will fit in the new space “Always measure before ordering”, and if it’s close, order one example ahead of time and work out time test that the questionable equipment can be moved in well ahead of the migration.You’ll want to either do a trial run to ensure any large equipment will clear tight corners or narrow openings or hallways, and that elevators can handle the weight of equipment you are planning to move. Ordering before measuring and/or ensuring that it’s physically possible to move the hardware (racks, specifically) you’ve chosen into your new space can prove a costly mistake. www.device42.com

7. 6. Underestimating the time necessary to complete the work • “Be extremely careful with pre-move calculations, always erring on the side of caution and budgeting extra time where feasible to allow for variations in things that are outside of your control. Underestimating could result in what is otherwise a successful move to be viewed in the eyes of management as a move that took too long, and resulted in too much extra downtime”. www.device42.com

8. 7. Lack of a test plan • “ Lack of a test plan can cause entire moves to fail“. • A test plan should detail how each step will be validated, and who will sign off on each test’s success. • This ensures that the “blame game” is avoided… and: • Applications are available • Performance is within acceptable ranges. • Things are otherwise working as expected. www.device42.com

9. 8. Lack of a back out procedure • A back out procedure is a “must”, and should be incorporated into the same plan that will be followed during the move. • In the case that it becomes necessary to back out and postpone or abandon a move, both the staff performing the work and executives will be glad that it was prepared. • It is also critical that the plan detail out exactly what sorts of failures will trigger the back out plan, and exactly who has the authority to determine that a failure has occurred and the authority to put the back out plan into action. www.device42.com

10. 9. Assuming you are “done” with your piece without thoroughly verifying “The definition of done for each step must be carefully thought out to avoid lengthening the migration and extra unnecessary and costly downtime”. www.device42.com

11. 10. Lack of / Bad communication and Not coordinating with others • Communication can affect a migration’s success in many ways. • Prematurely executing migration steps before others are ready can cause work to be duplicated. • Conversely not communicating you’ve finished can result in others waiting around to do their parts, lengthening the migration and possible associated downtime. • Providing executives a dashboard or another agreed upon means to keep tabs on progress, updating application owners, and communicating with users are all important as well. www.device42.com

12. server racks 11. Ordering the wrong As the computing industry has evolved, so has the drive to increase compute density in every way possible. Be sure before you order 55 RU racks that your facility has: • the ceiling height to fit them, • the floor strength to hold them, • the power density to power them, • the cooling capacity to cool them! “Any one of these factors being overlooked can be a show stopper, causing larger racks to remain underutilized, resulting in wasted capital outlay, or worse, having to return them if they don’t fit in the building”. www.device42.com

13. 12.Ordering the wrong server form factor • Be extremely attentive when ordering hardware for a migration!!! • Not only will mistakes like the wrong form factor, or the wrong rail kits really mess up a migration, but they can also be extremely costly to correct even if caught before move day. • The logistics and cost alone involved in repackaging, addressing, reloading, and shipping back hundreds of servers, switches, or even rail kits can put a real dent in the perceived success of a migration. www.device42.com

14. 13. Not ordering enough racks or hardware • Calculating the number of racks and servers required for a migration involves a lot of calculation. • Rack size, the computing power of each server, and the amount of space each takes up must be taken into account. • Getting these numbers right involves careful calculation that considers. • The capacity that is required to run today’s data center. • Room for growth. • Taking into account hardware that will be migrated physical to virtual. • Memory and processing requirements. • Density of applications that your organization is comfortable running on each server. • Accounting for peak load and failover capacity. • For a large move, a slight miscalculation in one or more of these factors can result at the worst resulting in a completely failed move, and at best case resulting in a lot of extra spend. Though “measure twice, cut once” doesn’t exactly apply, the principle behind it surely does! www.device42.com

15. 14. Not taking power availability into account • This is the flip side of the coin to selecting rack size. • Full racks use a lot of power, and the larger the rack, and the more powerful the hardware, the more power needed. • The type of hardware to be racked is also a big factor. Idle servers will use a lot less power than fully loaded servers, while a rack full of spinning disks is going to use a lot more power than a rack full of SSD storage, the latter being much more power efficient. • “ When calculating for power, rack size, what is to be racked, and power requirements of each item at full load must be taken into account”. • 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,so machines must be powered up in batches that take this into account to avoid overloading a circuit. • Finally, don’t forget to properly size UPS solutions to support the denser, more power-hungry loads that larger racks with smaller, more powerful hardware can require! www.device42.com

16. 15. Under or overestimating cooling needs Cooling needs are often thought of as a building requirement, and can be an afterthought in the minds of those planning a migration. Unfortunately, it will be at the forefront of your mind if you realize that you don’t have enough cooling to support the loads you’ve migrated in! In a worst-case scenario, this could result in having to power off hardware to lessen the cooling load, or even halt a migration in its tracks until larger units can be installed — assuming they can be! Install too much cooling, on the flip side, and you will be stuck paying for oversized cooling units that cycle too quickly, shortening the equipment’s lifespan and while not operating at peak efficiency. All this can be avoided with careful calculation and analysis ahead of move time! www.device42.com

17. 16. Migrating to a hosting provider without testing their claims • Make sure that you’ve exercised your hosting provider before going all in with them. • Talk to their other customers, if possible. • Don’t spring for the lowest cost provider based on dollars alone. Some hosting providers have been known to over sell their capacity, and at peak times, all customers workloads are affected and can perform poorly, or not at all. • Ensure that if a data center promises you a 1gbps internet pipe, they aren’t selling that same 1gbps to three other customers! • Ask the right questions, and do due diligence ahead of time before making the jump. www.device42.com

18. 17. Having no plan for what to do with hardware from the old data center Getting rid of old hardware can actually turn out to be a significant cost. There are many companies that specialize in doing just that. In some cases stringent requirements must be followed if your organization is in the business of handling certain kinds of sensitive data such as medical records, financial or credit card information. The used hardware market is huge, so if the hardware isn’t that old, there can be significant cost savings in re-selling it. The bottom line is to think about what you will do with old hardware after you turn it off, as if you haven’t made any plans, you’ll be stuck paying data center rates to store it until you do! www.device42.com

19. 18. Migrating to a new technology based on marketing material & buzz over true business need — and dealing with all the issues that come w new tech (instability, headaches, downtime) … • “Avoid being the “new tech guinea pig.” Do everything in your power to demonstrate to stakeholders the risks involved in migrating to new technology “X” if you know for certain it will do more harm than good, or that in the end it won’t provide benefit to the company even if it works as advertised. • It’s best to avoid this situation all together, but sometimes it isn’t your choice. If there is still push back, try to work out an arrangement to do a partial, trial migration to the new technology before going all in. www.device42.com

20. 19. Rushing to migrate workloads to the cloud without having the in-house expertise with the experience to manage cloud workloads efficiently Migrating workloads to the cloud is only one step of the process, and you must be sure that you have the expertise to accomplish it. However, once everything has been migrated, you must also be sure that you have the on staff expertise to manage cloud workloads, as the methodologies behind their monitoring can differ greatly from an onsite data center, no longer having the ability to walk into your server room and move wires or hook up a keyboard and monitor to an unresponsive misbehaving mission critical server. www.device42.com

21. 20. Not taking time to move the actual data into consideration • Underestimating the bandwidth of a “station wagon full of hard disks / tapes” • Moving terabytes of data takes a significant amount of time and bandwidth. • The way this will be accomplished, and the timings must be worked out ahead of time. With larger databases, this downtime can be very significant , such as is the case with dumping a MySQL database. • Testing the integrity of the data once it arrives. • Being sure to know who can and will test and sign off on it. This all requires pre-move planning, and it very well may be decided that the best way to move the data is via a trunkload of high capacity harddisks or tapes. www.device42.com