Summary Experience Network Startup Network Migration App Delivery Major Upgrades Tools & Templates Help Desk Standardising Office Move Write Apps Write Documentation New User Guide Technical Skills

Plan and direct computer-related aspects of your office relocations.

When H&A's main office, home to about 150 staff at the time, moved from Cambridge to Boston, there was a lot to coordinate. Everything that had to do with moving the network and the workstations was my project. It was my responsibility to plan how it would be done, prepare adequately, anticipate every possible contingency, and accomplish the move itself within a very tight schedule.

Well. It turns out that a move of this magnitude generates about a million questions and issues.

It started months before the actual move, of course. The space we were moving into didn't exist yet; the building was a derelict shell that would be restored (hopefully) before we moved in, so we got to design the layout of our future space ourselves, which was great, but it meant questions. For example:

• What were IT's space needs? What would our space needs be for the next ten years (the length of the new lease)? What would be the most efficient layout for IT's area?
   
• How big a computer room would we need? What should its layout be? What furniture (tables, etc) would the computer room need?
   
• How should we wire the building? What should be our standard configuration of jacks in each office? What non-office areas should be wired, and with how many drops?
   
• The new space was all on one spacious floor. Was it longer than the 10baseT maximum (~100m)?

I had to think about preparation for moving the network and all the computers. For example:

• What changes to the network would be required in the new building? For example, H&A has printers located throughout the building, rather than just a few central printers. People would be sitting in different places in the new building; their default printers would all have to be changed. Also, in the old building we named printers by their location relative to the compass; we couldn't do that in the new building. All the printers would have to be renamed. What should we call them? Where should they be located, for greatest efficiency and user convenience? You get the idea.
   
• How much preparation for network changes could we do in advance? How much would have to be done after the move, and how much time would that take?
   
• Just to add a bit of fun, the move would actually split the office in two--our lab wasn't moving. This meant we had to split them off into a separate network of their own, with their own server, etc.
   
• What dependencies did the other offices have on us? What preparations would have to be made to minimise their disruption during our downtime?

The move itself also required a lot of planning. We had only a weekend, and a lot to do. For example:

• How should the servers and clunkers¹ be moved? Should we move them ourselves, or trust the movers? If the movers did the job, could we count on them to deliver the servers immediately, or would they get lost in the shuffle? We needed the servers right away so we could start on the reconfiguration of the network.
   
• How could we get so many workstations (about 150) broken down, moved, successfully delivered to the correct office or cubicle, and set up again in working order over the course of a weekend? Especially considering that we had a network to set up, which we were expecting to take the entire weekend by itself?
   
• Who should do what during the move? With only a few people in IT, and very limited time, we had to know in advance what our jobs were so that it could all be done efficiently and quickly; we couldn't have everyone standing around saying "Now what?"
   
• We needed an accurate map of the new patch panel, and all the offices and which jacks would be in use, in order to jump the jacks from the patch panel to the hubs. We couldn't just jump every single jack we'd wired. We didn't have the hub space to do that, because we'd overwired in anticipation of future needs. We had to know which jacks actually needed to be jumped.
   
• Would it even be possible to have the whole office up and running again by Monday morning, or should the company tell everyone not to bother coming in (obviously very expensive)?

The move was so complex that I couldn't possibly present a coherent description of everything we did to prepare, or the move itself, or the setup of the network and workstations during the weekend. During the months before the move, I constantly racked my brain for things I'd overlooked. The move itself was like being ringmaster of an eight-ring circus. But I have to say, it was quite exhilarating.

If you're curious, you can look at the checklist (Acrobat; 9 KB) I used during the move. This is a concentrated summary of all the planning and preparing. The checklist was a living document; it constantly got modified and updated as I thought of new problems and new ways to be more efficient. The items in red are the heart of the move--the setup of the computer room, and the reconfiguration of the network.

And yes, it was all up and running on Monday morning, as though nothing had happened.

¹Clunker: This is what we called a workstation that is dedicated to running an infrastructure-related task. For example, the email system has agents, which have to run all the time; we install and run them on a dedicated computer, which we then called a clunker. The term was indicative of the quality of computer involved at the time (they're better these days). Some people prefer the term "boat anchor".