The Perils of Server Migration

Arthur Cole

The perils of consolidating data center operations in the wake of an acquisition came into view this month as customers of Web-hosting firm Hostway found themselves without service for several days. It seems that on July 27, Hostway began moving close to 3,700 servers that it gained from Affinity Internet from Miami to Tampa, a process that was supposed to suspend service for several hours at best. As the disruption continued into early August, tech support and e-mail were overwhelmed.


Although an official explanation as to what went wrong has not been released yet, there is no shortage of outside opinions on the failure. Basically, though, there is a right way to move servers and a wrong way. Certainly, a server migration isn't as simple as unplugging an entire server farm, trucking it to a new site, and plugging it back in again. Systems must be backed up while the new center is configured and tested offline.


More and more, data center integration is becoming a determining factor in whether an acquisition is successful. That's why many consultants are opting for generic infrastructure; things like power supplies, connectivity devices, even cabling. As long as two centers can communicate with each other on a basic level, there's nearly always a means of migrating data and applications from one to another.


In many ways, though, the technical integration is a cakewalk compared to the cultural one. Once instituted, organizational processes are not easily abandoned, even if those who set the policies are let go after the merger.


One thing to keep an eye on going forward is whether virtualization will simplify or complicate the migration process. Microsoft, VMware and Xen all have versions of live migration technology in their platforms, which lets you move a virtual machine from one physical server to another quickly and easily. While this is designed for load balancing and other management functions within a data center, it's not inconceivable that this ability could be used over a WAN, possibly eliminating the need to move servers altogether.


No matter how prepared you are, however, server migration and data center consolidation will most likely continue to be a crap shoot. Some will go smoothly. Others won't. The only thing to do is make sure the long-term gains outweigh the short-term disruptions.

Add Comment      Leave a comment on this blog post
Aug 10, 2007 3:22 AM S.M.Khurram Quaseem S.M.Khurram Quaseem  says:
I have been involved in two major Data Center Movements for my clients and probably going to involved in a third one by the 3rd week of August. So let me write a couple of basic yet essential tips:1- Always write things. Don't become overconfident! This will help you and your team to understand things going on, and what would be going on.2- Always do a live simulation before the transfer. No matter if its a single server, a server farm of a whole data center.Hope this Helps.S.M.Khurram QuaseemCEOSK Web Technologiesceo@skwebtech.com Reply
Aug 13, 2007 3:36 AM Fedor Fedor  says:
Server migrations should always be carried out under the MRFM concept (Make Room For Murphy). Most project leaders do their best in the preparation phase to avoid bottlenecks, and eliminate every risk they can think of, but ingnore the ultimate 'what-if' question. What if, in spite of all precautions, something goes wrong? Is there a plan B to fall back on? What is the buffer in terms of time, people and systems if I need to reallocate resources on the fly? If there's no buffer, there's no room for mistakes. And we all know that mistakes will happen. Reply
Aug 16, 2007 2:04 AM Edison Hoolasie Edison Hoolasie  says:
We are a small Credit Union in the Caribbean and never had to migrate more that a few serversat a time. Our team observes the basic rules most of which we share with you as follows :We plan our window for migration very carefully, identifying the ideal time to migrate, document the processes and configurations (soft and hardcopies), identify tasks and assign responsibilities, use manufacturer specified software tools, make offline backups, undertake Test runs before cut-over, ask power users to accept Test runs, undertake full cutover only after sign-off(s) of Test runs, seek user acceptance before sign-off, and retain old information for at least 6 months.Edison HoolasieCorporate Director ITHindu Credit Union Group of CompaniesTrinidad, West Indies Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.