Server Migrations: How to Minimize Risk and Downtime

The idea of a server as a discrete, single, physical entity is fading fast. The need to move from one platform to another due to upgrades, virtualization and other technology events is now commonplace. Here, Knowledge Center contributor Michael DeNapoli explains how to efficiently manage server migrations between various platforms with minimal downtime and maximum safety.


We all know the situation: Solution A is housed on Server No. 1, but Server No. 1's reliability may be problematic for a number of reasons. It could be failing, overdue to be refreshed or require virtualization to conserve resources-just several of many justifications for migration to Server No. 2. The challenge is to accomplish migration without either losing requisite material that Solution A needs to function or causing so much downtime that users enter into an open revolt against the IT department.

So, how do you handle this quandary in which you want to proceed cautiously through migration and not risk losing the entire system-and do so while your users are demanding no downtime? The following are five tips that can help you strike a balance.

Tip No. 1: Know your dependencies

Though the IT staff may be unwilling to admit it, some may not fully understand how a solution set works in a given migration strategy. Take Exchange Server, for example. Changes to Exchange Server can be accomplished in a variety of ways, from simple mailbox-move operations for single-user migration to third-party solutions that can transport the entire server to a new domain, if necessary.

The predicament is the impact this move will have on systems such as Good Technologies services, Blackberry Enterprise Server, Lync and the suite of mobile technologies native to Exchange (Outlook Web Access/App, Outlook Anywhere and ActiveSync). By not taking these ecosystem solutions into account during the mailbox server migration, you can derail all of your mobile users very quickly. Failing to fully understand all the orbiting systems that your target migrated system either depends on or has dependencies to sets yourself up for a real-life migration nightmare.

Tip No. 2: Know what must be moved

A solution set can consist of one or more components across one or more server or hardware resources. A good step during any migration is to assure that you first know how the solutions work and what moving parts need to be accounted for within the system you are migrating before starting the actual move. Fax servers are a great example of this type of solution, as many require physical fax cards in order to operate properly. Even the very best migration plans will be sidetracked if you have not ensured that fax cards are compatible with the new hardware/virtualization platform to which you're trying to migrate.