• Use VMs. You are talking about a dev/staging/QA environment where performance is not an issue. If performance testing is part of the remit, then you should be using hardware as close to your production environment as possible. You should also have plenty of scripted workloads to simulate different production load patterns.

    Getting back to the VMs. VMs are really useful for dev work. Get your VM to a point where is satifies your dev requirements, snap it and the you have an image you can switrch in at anytime. Ditch the old image that may be FUBAR by that point and everyone is happy.

    As for 2005 v 2008. If you are developing for production machines that are 2005 or 2008, then develop on an instance that matches the final production destination. The differences will bite you one day. Best to go with like for like as much as possible.

    SQL licensing in a deve/test environament is simple: there is no cost. As long as you can clearly satisfy MS in an audit that your dev environment is strictly just that, then you are OK. To make it clearer use SQL Developer Edition. The only trouble you may come across is a developer uses a SQL feature that is only availabe in the Enterprise edition and your target production machine is a Standard instance. This can be managed by having clear requirements and some code review.