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.
Email
Print
