Moving a server network is not an easy task, but sometimes it is necessary. If you ever have to move your server network, the following tips may come in handy.
Because I write about such a variety of computer-related products and issues, I have to keep a lot of computers on hand. It finally got to the point that I was running out of room for all these machines. Rather than virtualize machines, I decided to buy a bigger house.
This meant I had disassemble my network of a couple of dozen computers and reconstruct it in the new location. Since my moving experience might be fairly consistent with what an SMB might have to go through when moving to a new facility, I'll discuss some of the tasks involved in moving a network.
Schedule downtime
An important part of the process is scheduling the necessary downtime. Your organization's key contacts and customers need to be aware of any anticipated service interruptions during the move. In larger organizations downtime, even if planned, is usually unacceptable. If this is the case for your business, you'll need to find a way to keep key systems online during the move.
You might want to consider investing in some new systems, and set those up at the new facility while your existing systems continue to function at the old facility. The old systems could continue to do the necessary tasks until you're ready to transfer operations to the new facility.
The only application that is absolutely critical for me is email. Since I run my own mail server, my email usually comes directly to me, rather than to my ISP's mail server.
The SMTP protocol is designed in a way that allows messages to be automatically resent if a mail server happens to be down or inaccessible when the initial delivery attempt is made. The problem is that most mail servers will only re-attempt delivery for a maximum of two days. Due to the logistics of my move, I was expecting to be down for about five days, so I couldn't depend on SMTP retransmissions for message delivery.
To avoid losing messages, I worked with my ISP and arranged for my MX record to be temporarily pointed at an ISP's mail server. When my mail server was finally back online, I switched the MX record back so that it pointed to my mail server's IP address. Of course, a bunch of messages were still stored on my ISP's mail server. I was able to use a POP client for Exchange to download these messages and place them in the appropriate mailboxes on my mail server.
Prior to the move I labeled everything. All my servers look alike, and I can't visually tell them apart. I bought a label maker and labeled each server with its name, primary IP address, and which KVM multiplexer port the server normally connects to. This way I could make sure to set everything up in the new location in a way that mimics the current location.
Cabling issues
When moving a computer network, you need to plan for reassembling the network in the new location. Before you move the first piece of furniture or equipment, you should plot out where everything is going to go.
Why is this so important? So you can be sure to order enough cabling. In my old home, all my servers were in one room, and my office (with all the keyboards, mice and monitors) was in the next room. This meant that each one of my KVM multiplexers was connected to a keyboard, mouse and monitor in the next room by a 20-foot KVM cable. In my new home the server room isn't that far from my office, but the route that the cables had to follow meant that my KVM cables had to be 70 feet in length. Had I not planned ahead of time and ordered these cables prior to the move, it could have resulted in unnecessary downtime.
You also need to make sure there is sufficient electricity for all your computers. You should also plot out the placement of server racks and other types of furniture. The layout of the new office will likely be different from your existing office, and furniture and server racks may have to be arranged differently. This affects not only the required cable lengths, but also how many uninterruptible power supplies (UPSs) you're going to need. For example, my previous network had two servers on each UPS. Server placement in my new home made this arrangement impractical. I had to buy another UPS.
Disaster recovery
You never know when a server could get dropped down a flight of stairs or the moving truck could overturn. It's critical you make backups of everything, and transport those backups separately from the servers themselves.
You also need a contingency plan. For example, what would you do if one of your servers failed to boot after being transported?
Prioritize servers
Finally, it's important to decide which of your servers are the most critical, and should be brought online first. The reason is because it can take some time to run cables as well as crimp cable ends. If you're not able to prepare the site ahead of time, your servers could be down for a day longer than necessary while cables are being run.
But if you prioritize your servers ahead of time, you can run cables for the most critical servers first, and bring those servers online. The servers can be running while you run cables for the other remaining servers.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
More information on this topic:
