eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Know What Might Be Moved
Tip No. 3: Know what might be moved
Once you’ve figured out the components that are absolutely required to be moved from the current platform, you should fully analyze what you may want to migrate or leave behind. There are always system components that don’t have to be migrated to the new platform but perhaps should be in order to minimize downtime and complexity.
For example, Windows system state information might be moveable (with the right tools) from one hardware platform to another. If this information can be migrated, then configuration of the new server becomes dramatically less complex, at least from a Windows and software perspective.
Tip No. 4: Set expectations and stick to your guns
Expect users to demand zero-downtime migrations from you and your staff. The unfortunate reality is that this dream of zero downtime is often impossible in the real world of migration. Even if you can physically migrate without visible downtime (such as for mailbox migrations in Exchange or Notes), you still want to give your staff some breathing room to deal with the unexpected. Granted, moving system state information and binaries, planning well and doing everything you can possibly accomplish ahead of time will minimize downtime. However, a promise to eliminate all downtime during major hardware migrations is one you will not likely be able to keep.
Set a realistic amount of downtime and make sure everyone from the IT staff to the users knows when to expect it and how long it is likely to last. If that is still unacceptable to the users, explain why you must disagree because of the potentially catastrophic risk that their demands pose to the system.
Tip No. 5: Get the tools you need
Migrations can often lead to unexpected consequences because someone didn’t read the fine print. One example: many native Physical to Virtual (P2V) tools require that data be in a “quiesced (database administrator transactions only) state” during the migration. For SQL or similar servers, this means the databases must remain offline during migration because of a major risk of data loss during the procedure. P2V tools also tend to be one-way prospects from your physical servers to virtual machines. This isn’t a failing of the tools but rather a limitation of their operation. That’s fine if your migration is only P2V but doesn’t help if you’re trying to move to another physical platform. They also can’t help if you find that, after migration, an application doesn’t behave as expected in the new environment.
Having the right arsenal of tools for your needs-and typically a mix of native and third-party tools-will ensure that you can perform the types of migrations you’re looking to do safely, along with a “rip and revert” plan in case things don’t go as planned. Through a combination of these five tips, you can ensure you don’t leave anything behind, and that you can move to the new platform with minimal and reasonable downtime for the migration operation.
Michael DeNapoli is a Solution Architect for Vision Solutions. He can be reached at michael.denapoli@visionsolutions.com.