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.