Datacenter migrations are challenging in their own right. Not only do all of the concerns in my previous blog, Planning a Datacenter, play in, but logistics also have to be negotiated. Often in a migration, parts of the old environment, like circuits, racks and servers, have to be moved. This can create a real logistical challenge to plan out the order of operations and method of migration. Not to mention, without proper documentation before the move, re-assembly can be an absolute nightmare on the other side.
Liability at this point is another huge point of concern. Is your 2005 F150 insured for the $500,000 of hardware you’re going to put in it? What’s your workman’s comp like should someone get injured on the job? What about the potential intellectual property loss if all of that data goes away? What happens if someone drops a server on the way? What if the SAN gets stolen out of the loading dock while being moved? It’s important to bring in properly insured movers for a lot of this work and get in writing what the reconciliation will be. Not to mention, if someone is going to get hurt moving heavy stuff, wouldn’t you rather it be an external contractor than one of your highly paid IT staff?
Timing is one of the largest problems with migrations. Some businesses can take an outage where they’re down Friday night through Sunday on ALL systems, phones, internet, WAN, servers, etc., but it’s becoming increasingly common that companies can’t be down that long. We’ve seen companies begrudgingly agree to 16-hour downtime window, but that 16 hours may still not be enough to complete everything. The little things REALLY add up on the schedule of a lift-and-shift migration. For example:
- In order to validate server functionality and health, pre-existing issues must be known and documented before you boot the server up at the new site and wonder, “Does it normally give this error?”
- Plan time to shut down servers. This may take longer than you expect if you have multi-tiered applications.
- Perform one final backup on all servers, firewalls, storage array configuration, SAN switches, etc. just in case something goes awry. Switches will also need to have memory written and backed up.
- Un-rack servers. This may or may not be a major concern depending on the type of rails.
- Unplug all cables on switches and networking equipment. This can take MUCH longer than you would expect, and you can be left with bleeding thumbs from pressing a couple hundred RJ45.
- Cables need to be removed and organized if they are going to be used later (normally we recommend new cables, as the cost is low and they are almost certainly going to work better than four-year-old twisted and kinked cables).
- Un-rack all switches and networking equipment. Be prepared for at least one stripped screw that you WILL, without question, have.
- Remove carrier equipment patch panels and power if the racks themselves are moving.
Other questions to consider:
- Are you putting your backups in the same truck as your production data? What happens when it gets rear-ended by a semi?
- What happens when you get to the new site and run into a critical problem you can’t overcome? Do you just move everything back to the old? Did you leave the old server room in a state you can repopulate? Or did you cut some patch panels out to make life easier?
All of those little details add up into serious time frames, and that’s JUST the disassembly — you will have start re-doing it all at the other side. The more equipment you’re migrating, the less control of variables you have, and the more cascading time loss you run into. Unfortunately, this is also one of the projects that throwing more bodies at doesn’t really help; you can only get so many people in each rack. This is one of the reasons that we do more phased migrations now, rather than the old monolithic lift-and-shift method. These migrations can more complicated, but greatly minimize the risk and the outage windows. They also generally allow for much more testing, validation, and easier failbacks in the event of a major issue.
If all of that seems scary, there’s good reason: these are very complicated and high profile projects. I’ve seen move projects with three days of unexpected downtime for lack of planning and foresight. Luckily, there are companies out there who do this kind of thing all the time, like us. We can help as much or as little as you want. Just with the planning of the migration, while your team does all the grunt work, or with a fully turnkey solution where we just leverage your team as SME on your network.