Evaluating SharePoint 2013

It is an exciting time for all of us in the SharePoint community. SharePoint 2013 is definitely one of the most anticipated Microsoft releases and many people have been waiting patiently to get their feet wet. Last week’s public beta marks a major milestone in the SharePoint 2013 journey. Whether or not your organization plans to upgrade to the new version immediately after the RTM – whenever that may be- the time is right to start preparing for it. Learning about ways to upgrade to SharePoint 2013 and what has changed in the upgrade process is an important step in getting yourself ready.

The SharePoint product team made a lot of improvements to the upgrade process, such as deferred site collection upgrade, health checks and many more. Each of these enhancements is worth a separate topic. In this posting, I’d like to highlight a change in the available upgrade approaches that might have a significant impact on the way many organizations move to SharePoint 2013. This release is going to be the first SharePoint release where you won’t be able to upgrade your SharePoint farm in-place.

Isn’t it a good thing? After all a common piece of advice from both the expert community and Microsoft themselves was to steer away from in-place upgrade whenever possible. Few would argue that this is a highly risky upgrade method. Still there are at least two scenarios where in-place upgrade is a feasible option that can save you time and effort.

Dry runs – Upgrading a scaled down replica of your production farm in-place is the fastest way to identify potential upgrade issues and resolve them before you run into them during the real upgrade. Many consultants recommended using a virtualized environment, which can be easily rolled back and enable iterative troubleshooting.
Hybrid upgrade – Another scenario that the in-place option enabled was a hybrid upgrade, where you detached all content databases from a SharePoint farm, upgraded the farm in-place and reconnected the databases to upgrade content. The main benefit of this approach is that your farm global configuration (including Central Administration settings, services, etc.) was brought to the new version automatically. Now that upgrading to SharePoint 2013 requires new hardware, you will have to manually transfer your farm settings to the new SharePoint 2013 farm. In case you didn’t document your farm configuration, you should probably start doing it now. Since STSADM is deprecated in the new version of SharePoint, there is no longer a pre-migration checker that can help you gather some of the important configuration details.

What upgrade options does this leave you with? There are basically two ways to move to SharePoint 2013: doing database attach or going down a content migration route. In both cases your first step will be building out your new SharePoint 2013 farm. You will need Windows Server 2008 R2 and SQL Server 2008 R2 or their upcoming updates to power your new SharePoint deployment. Then you will reattach your service application databases to upgrade them in-place. Finally, you will need to move your content using the method which fits your requirements. While database attach is the fastest way to move to the new version, it also bring over all the “mess” you may want to leave behind: unused sites, convoluted site structure, obsolete data, unsupported customizations, etc. If you need more flexibility, consider third-party content migration solutions such as Quest Migration Suite for SharePoint, which offers a rich set of granular migration tools to automate site level migrations and data consolidation from other platforms, such as Exchange public folders and Windows file shares.