So, you are happily migrating your SharePoint 2013 content database to SharePoint 2016 when the Test-SPContentDatabase command spits out:
Category : LegacySiteDetected
Error : True
UpgradeBlocking : True
Message : 1 site(s) using SharePoint 2010 experience.
Remedy : Please upgrade sites using SharePoint 2010 experience
in database [Your Content Database] to SharePoint 2013
experience before proceeding.
Wait a second??? We are migrating from 2013? How did a SharePoint 2010 experience get in there?
Root Cause
The content database you are migrating to SharePoint 2016 was very likely using the SharePoint 2010 Office Web Apps.
The Fix
Step#1: Locate the offending SharePoint 2010 site
- Launch SQL Server Management Studio (SSMS)
- Connect to the offending content database
- Execute the following query:
SELECT als.id, als.PlatformVersion, aw.Title, aw.FullUrl, aw.ProductVersion, als.Deleted
FROM dbo.AllSites als
INNER JOIN dbo.AllWebs aw
ON aw.Id = als.RootWebId - Locate the entry that does not have a product version of 15. It will most likely look like this:
PlatformVersion Title FullUrl
4.0.25.0 Team Site sites/Office_Viewing_Service_Cache
Step#1: Deactivate (Delete) the offending SharePoint 2010 site
- Note the GUID associated with the site you identified in Step#1 above
(This will be the id column)
- Run the following query using SSMS connected to the content database:
UPDATE dbo.AllSites
SET Deleted = 1
WHERE id = ‘[GUID]’
also if you don’t want it deleted and keep it 😉 a quick sql hack (not recommended) is available.
update the PlatformVersion to 15.0.35.0
and productversion to 15 on the corresponding tables.
Excellent tip. I was working on an upgrade of a 2010 content database to 2016, and had performed the Test-SPContentDatabase and was reviewing the report and thought: what’s this? I’d never seen this type of error before in the report. Your posting helped me solve it. I then realized that this particular content database also contained, in addition to the root site, several sites located at wildcard inclusion managed paths that I had overlooked. I would like to note that direct modification of a SharePoint content database via SQL script is not supported, and, once you do so, you break any Microsoft Support agreement you may have for your content database until you can restore that content database to a pre-modification version. It;s OK to perform READ operations, but not any modification operations. See Support for changes to the databases that are used by Office server products and by Windows SharePoint Services for additional details. Instead of SQL modification, 1) try going back if you can and simply performing visual upgrade on these sites, 2) delete them either through the interface or through PowerShell “remove-SPSite.”