Migrating any Microsoft server product to a newer version is always a frightening proposition. In this blog post we'll cover the high-level overview of the SharePoint 2010 to 2013 migration process using Microsoft and industry best practices.
If you’re interested in migrating your existing SharePoint farm to SharePoint 2013, then the first things you need to know are as follows:
The only supported upgrade path is from SharePoint 2010. Thus, if your farm runs Microsoft Office SharePoint Server (MOSS) 2007 or earlier, then you’ll first need to upgrade to SharePoint 2010, and then re-upgrade to SharePoint 2013.
SharePoint 2013 has no direct upgrade path in any event. Sadly, even those with SharePoint 2010 farms must use a new install and database migration method (explained later in this blog post) in order to transition their environment to SharePoint 2013. Consequently, the term “upgrade” is itself a misnomer when it is applied to SharePoint 2013.
For instance, if you try to install SharePoint 2013 on top of an existing SharePoint 2010 server, you’ll see the dialog box that I’ve shown in Figure 1.
Setup has detected previous versions of this product on your computer.
A full discussion of the SharePoint 2010-to-SharePoint 2013 migration process would take farm more space than we have available here. Thus, I’ll provide you with the high-level steps as adapted from Microsoft’s own literature. For additional learning I suggest you study the resources I provide at the conclusion of this post.
In the meantime, “upgrade” to SharePoint 2013 consists of the following workflow:
- Prepare Your SharePoint 2010 Farm
- Prepare Your SharePoint 2013 Farm
- Copy and Upgrade Your Databases and Service Applications
- Upgrade Your Site Collections
Let’s take a closer look at each of these migration phases in more detail.
Prepare your SharePoint 2010 farm
We understand that we’ll decommission the SharePoint 2010 farm after our migration to SharePoint 2013 is complete. Before we do that, though, we have several punchlist tasks to undertake:
- Gather all configuration (topology, settings, etc.) of the farm
- Check all databases for errors and fix them
- Turn off the Web Analytics service application (SharePoint 2013 moves this service to the Search service application)
- Remove PowerPoint Broadcast sites (Removed in SharePoint 2013)
- Consider setting your SharePoint 2010 databases to read-only to “freeze” content
The suggestion to test all elements in this upgrade process applies universally. If you can afford to perform trial migration(s), then by all means do so.
This is my SharePoint 2010 Web app running on a Windows Server 2008 R2 SP1 server.
Also, I cannot stress enough how crucial it is that your SharePoint 2010 farm (or any SharePoint farm for that matter) be documented down to the most minute level. You don’t have to rely upon your memory and Excel to do this–there are plenty of third-party SharePoint documentation tools, including free ones. For instance, check out the Sezai SharePoint Auto Documenter for SharePoint 2010 from CodePlex.
Prepare your SharePoint 2013 farm
In the database-attach migration scenario, we must create a separate SharePoint 2013 farm, building it from scratch, and then gradually introduce the SharePoint 2010 content into the new farm. As you would reasonably and accurately expect, you’re going to lose some of your branding customizations, so be prepared to adjust accordingly.
Here are some major TODO tasks for this phase of the migration:
- Don’t use the SharePoint 2013 Farm Configuration Wizard. Instead, deploy all of your service applications manually and be sure to name their associated databases intelligently
- Complete all the normal post-installation farm configuration in your new farm: incoming/outgoing e-mail settings, farm security; Web application policy; logging, and so forth.
- Install any necessary language packs
- Recreate your customizations
Recall that your database back-end must be running either SQL Server 2008 R2 or SQL Server 2012 to support SharePoint 2013.
Do not create any Web applications at this point besides Central Administration; we’ll take care of that detail in just a moment.
Copy and migrate your databases
In this migration phase we need to concern ourselves with moving and upgrading our SharePoint 2010 farm’s databases:
- Content database(s): At least one for every Web application (except for Central Administration, we don’t need that)
- Service Application databases: Each service application installs at least one (and oftentimes many more than one) SQL Server database
Only certain SharePoint 2010 service applications can be migrated to SharePoint 2013; these are:
- Business Data Connectivity
- Managed Metadata
- PerformancePoint Services
- Secure Store
- User Profile
We’ll need to use SQL Server (using the GUI or Windows PowerShell, it does not matter) to back up the appropriate SharePoint 2010 databases and restore them to the SQL Server instance that hosts our new SharePoint 2013 environment.
Here we use T-SQL to restore a backed-up SharePoint 2010 content database to our SharePoint 2013 SQL Server database instance.
Once your service application and Web application content databases are successfully restored into your SharePoint 2013 database server, it’s time to create SharePoint 2013 Web applications, one for every Web application we had in our SharePoint 2010 environment. Be sure to use the same URLs and TCP port numbers.
Copy or re-create any Web application-level customizations as appropriate:
- CSS stylesheets
- Web parts
- Web.config tweaks
- Features/farm solutions
- Site definitions and templates
- .NET assemblies
Upgrading the service application databases can be tricky, so I’ll refer you to TechNet for the detailed step-by-step. Here is the general procedure:
- Start the service instances on your SharePoint 2013 server. The service is instance is the “engine” that powers SharePoint service applications. Think of starting your car.
- Create your service applications and restore your SharePoint 2010 service application databases. You’ll need to use Windows PowerShell for this procedure
- Define proxies for the service application; the proxy is the intermediary component that connects your service applications to the Web applications that consume their services
- Verify and customize the default proxy group membership
Now on to our content databases and user-facing Web applications. At this point we created the “empty” Web apps and re-applied customizations as necessary. We can use the Test-SPContentDatabase to verify the integrity of the SharePoint 2010 database, and then use Mount-SPContentDatabase to attach the database to its associated Web application. Again, for maximum control and flexibility, we should be using Windows PowerShell as much as possible.
Here we see our newly attached content database being migrated in our SharePoint 2013 environment.
Upgrade your site collections
The final step of the SharePoint migration process is to upgrade your SharePoint 2010 site collections. SharePoint 2013 includes most of the SharePoint 2010 templates, so your migrated site(s) should look pretty much exactly how they looked prior to the migration.
The site collection migration can be initiated either by a farm administrator or a site collection administrator. Microsoft recommends that you run a health check on each site collection by clicking the Site collection health checks link on the Site Settings page.
Here we decide whether we want to proceed with a site collection upgrade or instead try a demo upgrade.
To perform the site collection upgrade, navigate back to Site Settings and click Site collection upgrade in the Site Collection Administration section. As you can see in the figure, you can either preview the upgraded site, or initiate the actual upgrade.
Here is our fully-migrated SharePoint 2010 Web application running on a Windows Server 2012 box running SharePoint 2013.
For further Rrading: