Data Center Migrations: It’s in the Plan

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 Peldzus, Glasshouse TechologiesBILL PELDZUS
GlassHouse 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.

Add Your Comments

  • (will not be published)


  1. Ray

    I could not agree more. I've been involved with 4 Data Center migrations. 2 of those where Lift-and-Shift and 1 involved a WAN based migration across country and 1 was a LAN based migration using Metro Ethernet. The stress involved with the Lift-and-Shift was unbelievable because of the massiveness of the change and the 100% no way your trucking all this equipment back to the old data center approach. The issues we ran into during our migrations to new or identical equipment in the new data center involved a problem called "one-more-itis". When you run into problems you really need to stick to your guns on time constraints so you have plenty of time to roll it back. You can't keep thinking that one more change will fix it. When you are troubleshooting you must stick to that timeline. Cut your losses and roll it back. We can then take a look at why it failed and make another run at it. I look forward to part 2.

  2. Actually, I don't think I could DISAGREE more regarding so called "lift and shift" migrations. Our customers have been through literally thousands of these migrations, and have experienced the issues mentioned by the author in a fraction of 1% of these. For sure, great care needs to be taken in selecting the proper shipping vendor. We recommend choosing one that (a) packs the equipment in wood crates with the proper cushioning, and (b) does not outsource its crating to third-party companies that may or may not be qualified to handle server equipment. In fact, there are 100-200 companies qualified to ship your equipment for every 1 company that is qualified to pack and crate your equipment. Therefore, since most "shipping companies" are forwarders who do not even handle your equipment, a safer approach is to identify and vet a crating company that can ensure your equipment will travel safely, no matter who moves it. The crating company can likely recommend a shipping company, if it itself doesn't offer such services.