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:
What’s inside that file? Anything that SharePoint doesn’t know how to upgrade. For example:
Missing files (referenced directly from the DB)
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)
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  times in the data, is mapped to [Microsoft.SharePoint.WebPartPages.ListFormWebPart]
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.
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.
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”:
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.
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.
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!
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.
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:
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.