SharePoint 2010 database migration to SharePoint 2013

There’s been a lot of discussion about how to prepare and plan for a migration, what it involves, what are the best practices. In this article, let’s get our hands dirty a little bit. Recently I had to do another complete upgrade to SharePoint 2013, and I took the opportunity to capture a few notes and screenshots.

So. Your SharePoint 2013 farm is installed and ready. Today is the day: You migrate your content. What do you do?

Prepare your upgrade to SharePoint 2013

There are excellent TechNet articles about the SharePoint migration process. Very much recommended reading, not to say mandatory:

Reference: Overview of the upgrade process to SharePoint 2013

Reference: Upgrade and migrate to SharePoint 2013 (Resource Center)

Survey your existing farm

To be fair, you should have done this a while back. For the sake of having a complete picture, I’ll just go over the major points you should look at when you take stock of what content needs to be part of the journey.

Farm Solutions

Before the actual migration, you will want to have clear idea of all farm solutions installed on your SharePoint 2010 servers.  Do you have a plan for every custom or 3^rdparty package? Do they exist in 2013 versions or do they work as is? Any missing feature will be reported as such during the upgrade, and can potentially cause issues.

Don’t forget to check Sandbox solutions, if you have them on your farm.

For each of those added solutions, you will want an inventory of which site collection and web site uses what. This can potentially be time consuming to compile but might save you headaches later.

Web Apps

By now you should know which web applications will be migrated. Take particular note of their authentication methods:

Any web app still in Classic mode will need to be upgraded to Claims on SharePoint 2013

Alternatively, you can change it while it is still running on your 2010 farm, if you feel safe doing so. We will come back to that later.

Copy your content database from 2010 to 2013

Here you have two main options: Pause your 2010 farm to take a cold copy of the content databases, or perform a live copy. Since we want to test with minimal downtime, we take the second choice with the help of SQL Server’s Copy-only backup feature:

That will allow you to take a live backup of your DB without interfering with your normal backup schedule, which would do pesky things like clearing your change logs and compromising your disaster recovery plans.

After that you simply restore that backup to your SharePoint 2013 SQL Server, optionally under a new name. No sweat.

Create a target web application

When migrating a SharePoint 2010 content database to upgrade to SharePoint 2013, you need to hook it to an existing web application, obviously. However, most of the time your DB to migrate will include a root site (situated at the path “/” on that web application).

If you have several site collections at the same path, or in fact any web site in your web application with identical paths, conflicts will arise and some of your sites will be inaccessible. But you want to keep the same paths as before, otherwise any paths specified in your content (Links lists, for example) will be broken.

You also want to create your new web application with the same authentication mode as in 2010. If you didn’t upgrade from Claims to Classic in SharePoint 2010, you now need PowerShell to create a Classic mode web application in SharePoint 2013, as they are considered obsolete.

Reference: Migrate from classic-mode to claims-based authentication in SharePoint 2013

So then, the trick is to make a brand new web application, and just remove its content database (all this through Central Administration). It can live without any DB for now.

Test and Upgrade your migrated database

Let’s recap:

• You have attached your SharePoint 2010 content database in your SharePoint 2013’s SQL server
• You have a new web application with no associated content database

You can now test and upgrade (as required) your migrated database. To do so, again we look to PowerShell. The following command will inspect your database and produce a detailed report of upgrade issues found:

Reference: Test-SPContentDatabase PowerShell cmdlet

This is the point where you want to install all third party and in-house customizations. Then re-test your database. Repeat until there are no errors reported, or at least none that you will not be able to live with.

Mount your new database

Next, you can upgrade your database. You can run the upgrade by itself, or as you attach it to your web app. The latter is the preferred process.

But you can’t just add a SP2010 content database to SP2013 through the UI. You will need your tech guy’s favorite swiss-army tool: PowerShell. The command to use is Mount-SPContentDatabase.

Reference: Mount-SPContentDatabase PowerShell cmdlet

Browse your upgraded sites

We’re almost done!

You should now be able to browse your new, migrated site. At the beginning it will still present the SharePoint 2010 look and feel, with a small difference:

You will see this nice colored banner at the top. The first link will take you to the first step of the site collection upgrade process (TechNet).

Index your new content

All right! Your content is all migrated and upgraded, and ready to use! Let’s throw the search crawler at it now

Not bad, one hour for about 24,000 documents, many of them PDFs. And no errors! I can now take advantage of the much improved SharePoint 2013 Search Center on all my content.

All in all, this upgrade to SharePoint 2013 migration went pretty well. There are some third party web parts that I will discuss with the farm’s admin, and a complete Site Template solution which I don’t think will be functional in 2013, given the huge changes in the UI. But even that site’s content is fully browsable and usable as it is now, so likely it will remain in 2010 mode