Discover our new product to help you understand usage and control costs in Azure. Explore Overcast.


SharePoint Content Database Migration

Louis-Philippe Lavoie

Last time, we went step by step into migrating your SharePoint 2010 content to SharePoint 2013. The process seems to be fairly straightforward, and quite honestly it is. But there are a few things that can go wrong, or that just need a little extra care. In this article we will take a tour of the different monitoring, reporting and troubleshooting options provided natively by SharePoint 2013 to follow your content migration process.

Copying the SQL database itself is normally bump free. Yes, you have to take into account making it read-only or some other way to ensure that you don’t miss recent updates, but that’s IT and business planning, so we will not discuss it further.


In my previous article I showed you the PowerShell command Test-SPContentDatabase, but I didn’t go into the details of its output results. This is your first line of defense against SharePoint database migration headaches. As the name suggests, it performs thorough check of the database file without actually modifying anything inside.

Because that command writes straight to the console, you will want to redirect it to a file:

SharePoint database migration to 2013 troubleshooting

What’s inside that file? Anything that SharePoint doesn’t know how to upgrade. For example:

Missing Features

SharePoint database migration to 2013 troubleshooting

Missing files (referenced directly from the DB)

SharePoint database migration to 2013 troubleshooting

And other items such as missing assemblies, use of legacy (WSS 3.0) UI on sites, authentication mode mismatches, etc. all presented in the same format. Most of the time, the message is very self-explanatory, and you will be able to infer the proper solution.

Going through that result file and clearing all the errors should mean a very smooth migration. You can also go ahead and selectively ignore some. For most of reported missing items (web parts, event receiver assemblies, etc.), they will simply be stripped from the corresponding site, and any content that is native to SharePoint (list items, pages, documents, etc.) will still follow through.


Next, you will go through the Database upgrade itself (with the Powershell cmdlet Upgrade-SPContentDatabase, or indirectly through Mount-SPContentDatabase)

SharePoint database migration to 2013 troubleshooting

Nice, it tells you exactly where to look. That log file contains a lot of information, similar to a ULS log file, but only about the upgrade process you just attempted. What’s more, it also produced an executive version of the log containing only actual errors and warnings (the full log contains a log of informative and debugging lines). That version has the same path & filename plus « -error » appended.

Do take a peek at the full version however, as it contains some interesting health information about your content database. For example:

Legacy SharePoint features that you are still using. Don’t fear, most of them will be dealt with during the upgrade (search the web for the Id to know what it relates to. Here it is related to WebAnalytics, which is removed from SP2013/merged into Search) :

Feature [Id = 56dd7fe7-a155-4283-b5e6-6147560601ee, Scope = Web] is registered to be deprecated

How many times you are using every referenced web part (Custom or SharePoint):

Web Part Type Id [9f56656f-6aa3-0d55-a812-711bf65864ea], referenced [193] times in the data, is mapped to [Microsoft.SharePoint.WebPartPages.ListFormWebPart]

Claims conversion

During your upgrade, if you are migrating a Classic-mode SharePoint 2010 database, you will need to bump it up to the now-standard Claims-based authentication. To do so, you will use the Convert-SPWebApplication PowerShell cmdlet, and that one also produces a full report. However it will be embedded in the ULS logs and not a distinct file, so grab it before it expires away.

SharePoint database migration to 2013 troubleshooting

In the report, you will see two lines for each user account migrated to Claims:

'SharePointClassic', SPSite ' 8ddc9e30-375e-45e7-abc4-2aa50dc3fdea', SPUser 'TESTuser1': Starting migration of user.  

'SharePointClassic', SPSite ' 8ddc9e30-375e-45e7-abc4-2aa50dc3fdea', SPUser 'TEST user1': Ended migration of user. 

Whenever there’s a problem (most often a user that no longer exists), the second line will instead be several, stating that the given account could not be migrated. You can comb through the log and see if anyone important was missed.


Free Bonus: Download our guide to learn How to Increase Your SharePoint Environment's Performance.

Central Administration Reports

In Central Administration, while your database is mounted and being upgraded it displays as such instead of the normal status of “Started”:

SharePoint database migration to 2013 troubleshooting

You can also checkout the following two pages for even more status reporting:

Central Administration > Upgrade and Migration > Review Database Status

Here you get a high-level status overview of all your content databases. Clicking on their names will lead you to its full details page, where you can see the exact schema versions. This is also handy for planning through Cumulative Updates and Service Packs, since you cannot migrate a content database to a SharePoint farm that has a lower version.

SharePoint database migration to 2013 troubleshooting

Central Administration > Upgrade and Migration > Check Upgrade Status

This is the main upgrade report page. Any past attempt, failed or not, will show up in the top list, with full details in the lower part when you click an item. The details table also lists the corresponding upgrade log file.

SharePoint database migration to 2013 troubleshooting

And do not forget standard SharePoint monitoring

So you have all those migration-specific tools and pages, but, heed! Do not skip the usual suspects of SharePoint error reporting! Lest you find yourself on the receiving end of a critical service ticket!

ULS Logs

Many of the aforementioned commands and processes will spew out a lot of data into the ULS logs (always depending on your log settings). After each step, review the appropriate file.

Windows Event Viewer

Oft forgotten, but oh so useful for troubleshooting, you will want to go through your system events even when everything went flawlessly. In the event log you will find such things as jobs that never ran because they failed to initialize properly, failed logins, unexpected errors, and so on.

Health Analyzer

The SharePoint Health Analyzer runs automated checks on a great number of items. Sometimes they only pop up after a few hours (or days...) because of the timer job, but any good administrator is already checking that page on a regular basis.

In the end

Again, going through the migration of your SharePoint 2010 content database as outlined in the first article should be relatively painless, thanks to the amazing job done on that front by the SharePoint product team for SharePoint 2013. Soon enough you will be greeted by the familiar pink banner of SharePoint migration success:

SharePoint database migration to 2013 troubleshooting

But remember: A full content database migration is only one of the avenues you can take, and it is not always the one best suited for every situation. If your content is already well organized, up to date, without any need for cleanup; if you are confident you can re-apply every customization onto your new SharePoint 2013 farm so that everything will load properly; then you should definitely go for a full content database migration.

If you need something that will really speed up the cleanup and reorganizing process, as well as help with the migration phase, Sharegate is the tool for the job 😉

Check my other article on database migration if you want more information on the subject.

Hey, got another minute?

Learn more about external sharing and benefit from the full potential of your Office 365.

The Ultimate Office 365 migration checklist