In a side-by-side upgrade, SQL Server 2012 installs either along with SQL Server 2008 (or 2005) as a separate instance or on a different server. This process is essentially a new installation followed by a database migration. You may want to select this option as part of a hardware refresh or migration to a new platform, such as Itanium or x64. Because of the backup and restore times involved in a back-out scenario, if you have a sizable database, this is definitely the option to use.
As part of this method, you can simply back up the databases from the original server and then restore them to the SQL Server 2012 instance. Other options are to manually detach your database from the old instance and reattach it to the new instance, use log shipping, or database mirroring. You can also leverage the Copy Database Wizard to migrate your databases to the new server. Although this approach provides for a good recovery scenario, it has additional requirements beyond those of the in-place upgrade, such as maintaining the original server name, caring for application connectivity, and keeping users and their logins in sync.
Following are the arguments in favor of a side-by-side upgrade:
- More granular control over upgrade component-level process (database, Analysis Services, and others)
- Ability to run SQL Servers side-by-side for testing and verification
- Ability to gather real matrix for upgrade (outage window)
- Rollback strategy because original server is still intact
- Best for large databases because restore time could be sizable
The arguments against a side-by-side upgrade are as follows:
- Does not preserve SQL Server 2008 (or 2005) functionality.
- Issue of instance name for connecting applications.
Alternatively, you can consider an in-place upgrade (read more here).