Before you begin testing, be sure that you know how you will return the test system to a known state when you have a problem. You will use the same fallback plan when you migrate the production system.
During simple testing cycles, it’s sometimes faster to back out unwanted changes. However, this is not recommended for timed runs during benchmarking. You have to restore from backup after each timed run to return the system to a known state.
Back up all databases before and after the test system upgrade, as you would for a “real” upgrade. The backups preserve the layout of data on disk and help you avoid confusion due to fragmentation and page splits.
To ensure source code control, use scripts for all changes to objects. This makes it much easier to recreate your environment if necessary.
