Into each engineer’s life, some migration must fall. What started out as a simple necessity when something broke; has evolved over the years into something that gets done about once every three to five years. Hardware doesn’t break as quickly as technology changes, creating a double-edged sword for the folks on the front lines of the technological revolution. Instead of an easy and manageable flow of workloads from one platform to another, we’re instead faced with a mad dash to get everything onto the new hardware platform before 1) the old one gets so outdated nothing works properly anymore or 2) the end-users threaten us with bodily harm because there’s too much downtime for the migration.

The only constants that we have to look forward to are that we have a platform in place where everything is – for the moment – running properly and according to expectations. We also have a platform that is better, faster, or just all-around different. Moving from one to the other poses a wealth of challenges, but staying where you are creates stagnation and frustration. Arm yourself with the knowledge of some of the more common problems migrations can run into, and prepare your systems to overcome them.

Some of the potential pitfalls you might hit during a migration are:

1. Incompatible hardware: Moving between physical and virtual systems (such and VMware 4.x with vSphere or Microsoft’s Hyper-V for example) offer some unique challenges. Jumping between physical server vendors also has a habit of exposing interesting problems with hardware/software interactions. Things that theoretically should perform perfectly well on different hardware often do not.
2. Operating System/application incompatibility: Exchange 2003 was a great example of this one. Coming from an x86 platform, many Exchange 2003 Engineers would have preferred to migrate to the x64 version of the Server 2003 OS to gain more RAM and better performance. The problem is that Exchange 2003 cannot run on x64 versions of Windows, so when they attempted to do the installations for Exchange, no amount of switches could trick it into installing properly.
3. Lack of a knowledge base: As good as most engineers are today, no one can know everything about every application typically found in the modern enterprise datacenter. The result is at least one server that needs to get to new hardware, but for which you do not have the skill set to reinstall it properly with all the switches and settings intact.
4. Lack of downtime: This is the huge one for most folks. The servers are up and running right now and end-users rarely tolerate downtime without a fight. The problem is that, in order to move from one platform to another, the production system will have to be down for at least some period of time when it gets decommissioned.
5. The Great Unknown: In just about every datacenter I’ve ever seen, there is that one server that’s ten years old and not going anywhere. Either no one knows how the workload in question functions (see #3), or more often than not, the software and licensing involved is nowhere to be found. Reinstallation to a new server system is therefore out of the question, but eventually the hardware is going to fail and force the issue, requiring you to plan for it now or deal with it later as an emergency.
6. Planning for each of these potential pitfalls will not be an easy thing, but addressing the issues before you start your migration is vital to ensuring success. Some, such as learning about the applications in question or hiring temporary help; are relatively easy to accomplish. Others, such as hunting down licensing that may no longer exist or properly provisioning virtual machines are not quite as easy. The best migration tools will help to overcome as many of these issues as possible.

Look for tool sets that can move between hardware platforms effectively, and that can help migrate not only the data, but also the system state and application binaries along with configuration info. This eliminates the need to manually install the apps on the target platform, and helps to make sure that the configuration of the application itself remains as near to identical as possible.

Finally, no matter what else you do, make sure you have the ability to do a test-run before you decommission the original server. Nothing is worse than finding out you have just migrated everyone over to a platform that’s about to blow up and knowing that you can’t go back without creating many more problems.

Migrations are nearly as inevitable as death and taxes, but with the right tools and lots of planning, you can survive and move with ease. Plan ahead, test everything and get the downtime you need.

• Bear Growth Capital Partners and Everything But Water Acquire Water Water Everywhere
• EPIC Media Announces the National Newsstand Launch of Everything for Men and Everything for Women Magazines
• EPIC Media Proudly Appoints Nelson Anderson as Creative Director for Everything for Men and Everything for Women Magazines