VMWARE

All your phys servers are good candidates for virtualization. You can P2V all your phys servers to ESX/ESXi without any, or at least minimal, downtime using vCenter Converter Standalone: https://www.vmware.com/tryvmware/?p=converter&ie=UTF-8&rlz=1T4GGLL_enUS398US398&q=vcenter%20converter. You can replicate VMs, if you have a paid version of ESXi or use ESX, by using a 3rd party tool such as Veeam (my recommendation):
http://www.veeam.com/vmware-esx-backup.html

You can easily recover your VM from b/u or by replica with Veeam. You can download and trial it for 30 days to play with it. It's easy to setup, use, and free support during the trial. :)

Regards,
~coolsport00

My first question would be "why?".  VMWARE is a great way to maximize the available hardware by allowing you to "multitask" (for want of a better word) one machine and have it fill multiple functions.  If you already have the machines in place, what are you looking to gain?

That said, I've always had good luck recovering in VMWARE.  The downside is that, in case of a hardware failure, ALL of your servers go down.  The good news is that hardware failures aren't all that common and you apparently have extra machines that can be put into service or cannibalized should the need arise.

Since you have the hardware there, I'd recommend setting up one as a test bed first.  If you're running two SQL servers, my guess is that the second one was added because of the load to the first - you certainly don't want to put all of your eggs into one basket which somebody already decided was being overtaxed.  AD doesn't put a load of strain on a server, so you can easily roll those two roles into it and then watch and see how it holds up before diving in.  

@ctwon_larry
Gain?...cost-benefit (heating/cooling, server maintenance, etc.) as well as (in my opinion) quicker recovery in the event of a VM OS or app failure; If storage is shared and segregated (mulitple datastores), not all VMs will go down because, hopefully, they will be dispersed between all the datastores as well as between a couple hosts. Having all VMs in 1 datastore isn't best practice (don't want all 'eggs' [VMs in this case] in 1 basket as you noted already) :)  He can go from several servers to at minimum of 2, and at minimal cost (3 ESXi hosts can be run from Essentials kit package for $495US).

You make a good point though to TEST, TEST, TEST :)  Also, whatever hardware is used, I recommend to go to VMware's HCL to verify its compability:
http://www.vmware.com/resources/compatibility/search.php

Regards,
~coolsport00

Yes its a good decision that is why corporations are virtualizing.  It is cost effective and more robust.  It allows you to move your entire system to other sites and much more.   The only problems we normally have are related to custom hardware device (odd unique things that dont virtualize) and machines that are using all of the available resources (all the memory , cpu, or excessive HDD activity) and this applies to machines that are rather new and beefy.  so if you old pentium 90 is working too hard then moving it to a new platform is the way to go.. but if it is a quad core with 16 gb of memory and it is using all it has then it should stay a physical machine.    that said you should also consider the fact that by moving to a VM you eliminate the hardware dependence of the operating systems.  thus you can keep an old O/S in production basically forever..

Yes, I forgot the HCL - good point on that.  Some items on the list have very fine distinctions between what will and won't work, even varying from one VMWare release to the next.

Admittedly, I'm a grumpy old man when it comes to certain things.  You say "virtualization", I say "single point of failure".  Like many such arguments, I understand that I'm in the minority and as far as everybody is concerned, I'm wrong.

Anyway, I have to go outside now and yell at some kids to get off my lawn. ;-)

indeed a single point of failure but unlike the old way you can have copies.. and just turn them on and it is as if nothing happened...
you also should put your Virtual system on a pretty good machine..  think server with raid 5 and dual power supplies..
also you can snapshot your VM's   you cant snapshot real machines.. :)

Think a financial system issues a software update.. you put it on and it crashes your financials.. in a physical system you are stuck..
in a VM you snapshot before the upgrade
upgrade
then test
if all good then Success..
if not just revert to the snapshot and try again or throw the update out the window.. :)

Again, I'm wrong, I know.  To your point, the snapshot is nice - but little different than creating a backup on a regular old server.  As for simply turning on a "copy" when there's a failure, that's of limited use if the motherboard dies or something similar.  In the old days, your SQL server (or whatever) would be down - a major issue, to be sure, but not as catastrophic as every server in your enterprise being down.

But I digress.

Back on point: take your most robust machine, make sure that the hardware is on the VMWARE HCL, test the heck out of it and I'd then add the servers that you currently have one at a time to the virtualized machine so that you can observe how it holds up to the strain in a live fire scenario.  I've seen lots of machines operate flawlessly in a testbed and then crash and burn shortly after rollout in a live environment.

ah.. but if your MB fails or similar if you have a copy of your VM's on a USB drive you can use any computer to quickly get your system up and running...
while you fix your main one.  
the only problems you have are synchronization of data..

Hi

Thanks for all your comments. SQL servers run 2 different applications.
My initial idea was to copy the existing servers (5) onto the virtual server and then replicate it off-site. (Eventually reducing the number of servers)
If, for example, one of the servers contains a virus can it effect the other applications even though they are encapusulated on the virtual server?

What do you mean by 'entire system to other sites and much more' ?

Thanks