Bill Peldzus is Vice President, GlassHouse Technologies. This column is Part One of a two-part series by Bill Peldzus on data center migrations and planning.
BILL PELDZUSGlassHouse Technologies
“Experience is the name everyone gives their mistakes.” Oscar Wilde
“There is only one thing more painful than learning from experience, and that is not learning from experience.” Laurence J. Peter
Those are just a couple often-used quotes that identify the opportunities to make “the next time better” based upon valuable lessons learned. And when tackling a project as large as a data center migration - whether it’s for a consolidation initiative, IT upgrade project, or moving to another data center or co-location facility - the devil really is in the details. And proper planning is crucial to mitigating these risks.
Taking a step back and looking over the last couple years, I’ve been focused on numerous migrations and lay out here some of the top challenges that I now plan for, in detail, ahead of time, rather than rallying the troops in the middle of the night to avoid an outage or, worse, needing to totally back out a migration at the eleventh hour. If it’s in the plans, regardless of whether you were actually spot-on in avoiding or working around the issue at time of execution, it demonstrates experience and proactive, rather than re-active, thinking. My executive and sponsor teams are always fans of “And if this happens, here are the steps we’re planning to take to work-around and/or solve that issue.” Makes those sunset reviews much more tolerable.
It’s all about planning for contingencies and expecting some level of things not going as scheduled.
Jumping right into some key activities within data center migration initiatives, here’s just a few items that proper, detailed planning ahead of time really helped:
New Technology Usually Means Other Upgrades Too
If migrating to new hardware during migration activities, it typically results in better and more up-to-date (and probably cost-efficient) IT equipment, whether it’s specific to the server, storage, or network-side. This is a good thing, actively addressing end-of-life and potentially obsolete or soon-to-be out-of-support gear.
But the flip-side is that new hardware almost always requires some other upgrades for compatibility and support reasons. The most obvious is the operating system on a server, needing a major or minor patch, or even a firmware upgrade. But, that’s just the tip of the iceberg. You need to look at almost everything in the application stack that may be affected. Some of those considerations include database versions, middleware versions, the application itself – whether home-grown or off-the-shelf. These types of upgrades can put a major burden on your application teams, from a certification and testing standpoint, and will have a major impact on timing and your project plan.
And then there’s that “you’ve got to be kidding” moment that no one saw coming. I think back painfully at a migration that was not adequately stress tested, and we found out, post-migration, that for a specific application-hardware combination, newer multi-threaded CPU chip-sets actually significantly slowed the performance of single-threaded applications. That was fun. And yes, we now ask if the application is single or multi-threaded and plan for appropriate and detailed performance testing.
Physical Moves [Lift-and-Shift] as a Migration Approach?
Many of my clients lean strongly towards a physical migration as a preferred approach. Logistically, you just un-cable, un-plug, un-rack, ship, re-rack, re-cable and re-plug, right? Well…not really. A few of those items that aren’t always considered as significant risks include:
- Does the vendor need to re-certify the equipment, especially for larger assets such as tape libraries or storage arrays?
- Do they need to be involved in the selection of shipping vendor?
- What are you going to do about the data if it’s located on a storage area network [SAN]?
- Are you moving the entire SAN too?
- What about NAS connectivity?
- What’s the time impact of physically shipping between locations?
- Are there special security concerns for data housed internally on the server(s)?
- What’s the back-out plan if the server gets lost or delayed? And it’s not cheap… and you need insurance too.
- What are all the changes needed once re-installed? Server name, IP address, firewall rules, backup infrastructure, network routing, DNS, Load Balancing, etc.
So, the Lift-and-Shift migration approach is usually my least preferred option for all of those aforementioned reasons. While it may work well in “specialty cases” such as stand-alone non-production lab and test equipment, I’ve just had a lot of bad experiences with this approach in general.
Stay tuned for Part 2 of this post where I discuss V-2-V Copies, the difference between “WAN away” and “LAN away” and how applications and connection speed also impact the progress of your data center migration.
Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.
