A client of our Consulting Services team recently decided to take the plunge and upgrade their SharePoint farm from Microsoft Office SharePoint Services 2007 (a.k.a. MOSS 2007) to SharePoint 2010 Standard Edition. They also decided to add a separate SQL server to their farm, which up until then had been a single-server farm. This wrinkle presented both opportunities and challenges for our upgrade strategy. I'll describe that strategy in this blog post.
SharePoint offers two broad strategies for upgrading from 2007 to 2010:
- In-place
- Database attach
In Place Upgrade
An in-place upgrade is probably what most people think of as an upgrade: the farm is temporarily brought down and upgraded in its current location. This process can be launched from Central Administration, and once the upgrade begins it is not possible to revert to the original instance.
Database Attach Upgrade
Database attach upgrades can be used to upgrade content databases without bringing the original farm down, and are reversible in that a failed database attach upgrade can simply be discarded while the original farm stays intact. However, to perform this upgrade without bringing down the original farm, you must install a separate 2010 farm on another server.
This new farm is used to perform the content database upgrade on a copy of the content databases of the original farm. The database attach upgrade strategy has one major shortcoming, in that it cannot be used to upgrade configuration databases associated with the original farm. To complete the upgrade, you must customize the new farm created to upgrade the content databases to match the original farm's configuration.
There is however, a hybrid approach which combines the best features of both strategies.
Hybrid Approach
We pursued this hybrid approach with our client with good success, and I would recommend it for any farm that has at least two servers in it. It begins with the database attach approach.
A fresh SharePoint 2010 Standard instance was created on a new server built to act as the SQL server for the farm.
To do this we used a great PowerShell script called AutoSPInstaller which can be found at http://autospinstaller.codeplex.com/.
This script automated the installation of SharePoint as much as possible and taught us a great deal about ideal SharePoint configurations.
After installing the new farm, we set the content databases of the old farm to be read-only in SQL Server and made backups of the content databases to a file share that was accessible to both farms. We then restored these backups to the new instance of SQL Server on the new server and attached them to SQL Server. After the databases were available to SharePoint, we executed a PowerShell command to attach the database to the new farm. This performs the upgrade, which is why this is called the "database attach" method.
Advantages
The advantages of upgrading your content databases this way is that the production farm never experiences downtime and any upgrade failures can be addressed until the upgrade succeeds. It was doubly useful for our client since they had to migrate their content databases to a new SQL Server instance anyway.
What Next?
After the content databases were upgraded, we started an in-place upgrade of the configuration databases. Before beginning however, we detached the content databases from SharePoint so that they would not be upgraded along with the configuration databases and the in-place upgrade would proceed faster.
The in-place upgrade was begun and finished a couple hours later. There were some complaints about sites that had been provisioned in site collections that had been detached, but these would prove to not be issues as the configuration databases were successfully upgraded.
Next we backed up and restored the configuration databases to the new SQL Server instance as we had done earlier for the content databases. When moving databases be sure to keep the names of the databases the same between SQL Server instances. Once this was complete we stopped all SharePoint services and brought the original farm down.
In order to use the configuration databases on the new SQL Server instance, we had to create a SQL server alias on the server hosting the original SharePoint instance redirecting to the new SQL server. For those who are curious, this is done through SQL Server Management Studio and is stored in the registry, so any alias created will persist even if SQL Server is uninstalled from the server the alias was set up on.
We then restarted SharePoint services successfully. As a final moment of truth, we stopped SQL Server on the original server and the farm continued to function. We then detached the content databases from teh temporary SharePoint instance and re-attached them to the newly-upgraded farm. (The database attach PowerShell command must be executed on the server where the web application they will be attached to is hosted.) Success!
Cleanup involved disabling the temporary SharePoint instance used to perform the database attach upgrades and to disable SQL Server on the original server.
Conclusion
All told this process was surprisingly painless and took about 24 hours. The duration of the upgrade process depends mostly upon the amount of content that must be upgraded. Hopefully this post will give others direction and allay any doubts about what is a sometimes stressful upgrade process.
Contact us if you want help upgrading your SharePoint 2007 portal (WSS 3.0, MOSS Standard, or MOSS Enterprise) to SharePoint 2010 (Foundation, Standard, or Enterprise).
Learn more about DMC's SharePoint consulting services.