Lessons learned from a server room migration

My company went through a physical relocation in January this year. The move itself was complicated and involved a consolidation of various departments to a brand new location as well as what amounted to a four-way reshuffle over another three branch offices.

As a result, the existing servers that were currently located at a central server room had to be shifted to new locations. To make it more challenging, the bulk of the actual move had to be completed on just one weekend to avoid disruption to operations.

I hope that some of the lessons I learned from this project will be of help to you.

Nothing beats an on-site visit

The decision for the relocation was a very late decision. An additional spanner in the works was that the site slated for the consolidation I mentioned earlier was not already an office. Because of that, everything from electrical and telephone points had to be set up from scratch.

Despite the number of matters that needed attending to, I was glad that I chose to pay a site visit on the day that the LAN wiring was being done. While examining the freshly pulled network cables cascading from the ceiling in the new server room, I realized to my horror that the contractor doing the infrastructure was pulling CAT-3 cables for the telephone points.

On investigation, I realized that the manager in charge of the infrastructure was unable to properly articulate to the vendor that we would be using an IP-PBX that requires a minimum specification of CAT-5e. Assuming that we were using a standard PBX system, the contractor then settled for CAT-3 cables - which were, after all, more than adequate based on his flawed assumption.

My on-site visit averted what could have turned out to be a very messy miscommunication. In the end, the contractor pulled a late night and managed to rectify the problem in time for the testing and commissioning of the IP-PBX the following day.

Be involved in everything that has the potential to be a show-stopper

Just days before the official move involving almost two hundred staff, I learned that the move might have to be rescheduled.

As I mentioned earlier, the new office was not formally an office. In fact, it was a relatively old school that was re-zoned and refurbished as an office compound. Needless to say, the infrastructure built to cater to the needs of a purely academic pursuit does not really fit the bill for a modern office well.

In this instance, the telecommunications provider based its commitment to the RFC (Ready For Service) date based on a survey on a soon-to-be defunct riser. Not everyone, at least those people to whom it mattered the most, was aware of this. As it is, the building management doing the refurbishing of the premises had every intention to demolish that which they found to be inadequate.

In fact, the old room was already half torn down just a few days before we were to move in. What of the new riser that was slated to replace the old one? It was not ready yet and the room allocated to it completely empty.

My mistake here was in assuming that since external infrastructure issues are not within my jurisdiction, they could safely be ignored. In this instance however, it nearly proved to be a show-stopper.

After some more twists and turns, the problem was fortunately rectified by having contractors run temporary wires to another riser that was somewhat nearer to the office.

Share the load among vendors

I had five different vendors covering various aspects of this move. Some might argue that this isn’t efficient since it increases the overall time needed to give instructions to multiple groups. In the final analysis, however, I’m glad I spread the load among a few vendors and contractors.

It boils down to the fact that pulling in a few companies–versus just one–allows me to draw on a bigger pool of resources. The logic goes like this; the vendors that I typically work with generally have just five staff members or less. By splitting up the work among different vendors, I ensured a maximum pool of help on hand the one weekend where I absolutely needed them.

A single, smaller IT firm might try to promise the sky, but might be unable to muster the requisite personnel, or lack the capacity, to attend to problems or last-minute changes. As you can imagine, failure to deliver is definitely not something I could have lived with in this instance!

There are a few other lessons I learned that I feel would be useful, and which I’ll share in my next blog. In the meantime, do you have any migration or relocation experiences that you might want to share?