I'm getting ready to migrate a server from old hardware to new hardware. I'm thinking of doing a P2P migration rather than actually rebuilding, reinstalling and migrating databases. The servers are Dell 2950s with Hardware RAID, running Windows.
Options include: using a software solution like Platespin, or break the mirror on the existing server and mirror the drive onto the new server, then rebuild the mirror again on the new server so both drives in it are new drives. All the hardware will be similar, although the targets will be three years newer.
Words of wisdom? Warnings? Software suggestions?
I'm going to be a wet blanket w/ my answer. If you can rebuild the machines, I think that would provide you the most stable "known quantity" environment. Unless the applications are such a huge time sink as to cause a "migration" to be a net win, I'd think that the time spent making the migration solution work well could eclipse the time just to rebuild by hand (and, besides, it's probably not a bad idea to use this as an opportunity to create or refresh the documentation of the configuration of these server computers).
To my mind, migrating a 3 y/o Windows installation means migrating a lot of old hotfix uninstall files, potentially garbage files and registry information, and a general "cruftiness". Unless you've done a really good job keeping these machines clean, there's probably some of that cruft that will migrate over.
OTOH, if you've got a particularly touchy application and this is a "known working" environment that's been highly tweaked you might see a net win in migration. I'd play devil's advocate and say that all that tweaking should be documented and reproducible. >smile<
I guess it comes down to how painful it is to rebuild the applications and transfer the data. The OS and drivers should be easy and a non-issue.
I do this often using StorageCraft ShadowProtect IT Edition. You can load in all the drivers for the new system before booting it.
Sometimes I've had luck with installing the storage drivers before migrating, and then going from there.
In my experience the only time I would image/backup a server and put the image back down was on same hardware. I reconfigured the RAID on the box (Dell 2850) when I added new Hard drives. The solution I used was Acronis True Image with the Universal Restore feature just in case I had to restore the box to dissimilar hardware. Acronis is a good product and gave me the flexibility to partition/format the disks as I want and then put the image in the size I just made. With that said I would recommend building the server from scratch for the following reasons:
One of the other issues that I foresee when moving from old hardware is, if you are moving a Windows OS, Device Drivers will be different, Chipsets, RAID controllers, Processors, NICs, etc. Doing a clean build will eliminate the hassle and garbage left behind if you ported the old system to the new hardware
This sounds like an excellent time to test out your backup and restore procedures and practices. ;-)
Unless this box requires 100% perfect uptime, I'd do a restore on the new box using the most recent full backup (you are doing regular backups, right?) of your existing box. I'd probably do one test run, possibly using a slightly out of date backup, then once I was sure everything was good to go, I'd get a current (right now) backup, and restore that to the new box.
You could look at a tool like Symantec's Backup Exec System Recovery Server Edition. It should handle the transition between the dissimilar hardware.
http://www.symantec.com/business/backup-exec-system-recovery-server-edition
You can drop a backup from one server onto new tin, but as has been said, hardware drivers will fail and cause problems. The way to do it is:
You might need to redo the system state restore after this. You use the same name because some backup programs (I'm looking at you, Arcserve) won't restore the backup to a different name (instead it tries to go over the network). You use the built-in backup because patches can make a third-party's backup program not able to properly restore the system state.
You can still have difficulties after this, like weird driver issues. And database servers are horrible if the logs didn't commit fully before backup. So you may need to test it out a few times. This works for Windows 2000 and 2003, and the order you do the system state and repair mode install can differ between 2000 and 2003 and depends on service pack level as well.