Handling the Virtualization Migration
Every infrastructure is different, so there are no ready-made plans to move servers from the physical to virtual realm, but there are general rules that you can follow.
The first concerns the use of Physical to Virtual (P2V) migration tools. These are available from a wide variety of vendors, and may or may not be included in the virtualization products you have chosen.
Some are better than others, but many servers can be successfully migrated in this manner, saving time and hassles up front. In some cases--usually with servers running niche software, or servers requiring the use of hardware keys, or licenses that are bound to specific physical server elements like ethernet MAC addresses. In some cases, using P2V on these servers is more problematic than simply rebuilding them as virtual servers, but there's no clear-cut way to tell without trying.
The good news is that in most cases you can attempt a P2V migration of a server without causing problems on the physical server. If the migration fails, the physical server can simply be powered back on without data loss.
That said, before any migrations take place, make sure to test your backups. Always have a backup plan in place should something go awry.
There are servers that shouldn't be migrated using P2V tools. A common example is a Windows Domain Controller. It's far simpler and less problematic simply to build a fresh domain controller on a virtual server and bring it up as a full domain controller then retire the physical servers once all replication has taken place and the virtual servers are functioning normally.
It's also a good idea to retain a separate physical server as a domain controller, so that not all your domain controllers are virtualized. This isn't a necessity, but without adequate high-availability features, this will provide a substantial safety net in the future.
Other servers can either be migrated using P2V tools, or simply rebuilt as virtual servers. In some cases, rebuilding the servers is a great way to clean out the cruft left behind from older physical servers, providing a clean slate as you transition into the virtual world. Remember, using P2V to migrate a physical server is unlikely to fix any existing problems, and may actually make them worse. If in doubt, you can always attempt a P2V and leave rebuilding the server as a fallback position. http://en.wikipedia.org/wiki/Cruft
It's important to keep track of IP addressing and physical and virtual server presence. When you're doing a P2V, take steps to ensure that there isn't a time when the physical server and its virtual doppelganger aren't running simultaneously. The P2V process retains the entire presence of the physical server, including the names, domain membership, and IP addressing, so having two present on the network at once will cause significant problems. The best idea is to power down the physical server and remove the power cables following the migration, then power up the new virtual server.
The process of converting a physical server infrastructure to a virtual infrastructure doesn't have to happen overnight. In fact, it shouldn't. You can start small by choosing one or two physical servers to convert, and let them run for a period of time as virtual servers in order to determine their viability. You can convert one or two servers per day, or per week--there's generally no need to attempt a full conversion all at once.
It may be of benefit to combine a virtualization initiative with a software or OS upgrade, perhaps migrating to Windows Server 2008 for some servers as you transition to virtualization.This allows you to test both the new virtualization platform and the expected behavior of the new servers while retaining a fallback position with the existing infrastructure.
It also allows you to start clean with the new solution, which might be a breath of fresh air if you've been battling various Windows gremlins in the physical world.
Finally, as you progress through the migration, take your time at certain points to regroup and ensure that you're following your original plan. Also make sure that plan includes implementation and testing of backups for your newly-minted virtual infrastructure.
Once you're done with all your conversions and rebuilds, you'll most likely wonder how you ever lived without virtualization, and the effort and any uncertainty of the migration process will have faded away.
More Virtualization Resources: