Database Attach Upgrade from SP2016 to SP2019 - Database in an unsupported state when querying SPUser

Bradway, Drew 1 Reputation point

I have a database on SharePoint 2016 that was upgraded from SP2010 to SP2016 and finally to SP2016. The database attached, upgraded, and I can query users in the SPWebs without issue.
When I mount that database to SharePoint 2019, it upgrades and sites load without issue. PSCONFIG will complete successfully.
When I attempt to Get-SPUser in any of the SPWebs, it returns the following:

There is a version mismatch between the Web server and the content databases, and connections to the data have been
blocked to avoid data loss. This can happen when a service pack is not completely installed. Notify your server
administrators so that they can upgrade the Web server and the databases to the same version. For more information
about installing service packs and updates, see the Microsoft Web site (
At line:1 char:1

  • get-spuser -web $web
  • ~~~~~~~~~~~~~~~~~~~~
  • CategoryInfo : OperationStopped: (:) [], SPException
  • FullyQualifiedErrorId : Microsoft.SharePoint.SPException

If I dismount the content database and attempt to mount it back up to the farm, it tells me
Mount-SPContentDatabase : This content database has a schema version which is not supported in this farm.

I have about 10 databases on this farm in a similar state and Upgrade-SPContentdatabase returns:
WARNING: Database [SPContentDatabase Name=ARCHIVE_015] cannot be upgraded.

What can I do to bring these SPSites and the Content Database to a good working condition?

SharePoint Server Management
SharePoint Server Management
SharePoint Server: A family of Microsoft on-premises document management and storage systems.Management: The act or process of organizing, handling, directing or controlling something.
2,789 questions
{count} votes

4 answers

Sort by: Most helpful
  1. Matteo Zamori 86 Reputation points

    Hi @Bradway, Drew ,

    If you managed to execute the Move-SPSite successfully to move contents from a corrupted Content Database to a "clean" one than you should be safe.
    It would be considered unsupported if you have altered manually the DB Version table using T-SQL

    As far as I understood, you made a lot of migrations as originally the DBs where on SP2010 and you went through all versions till SP2019 (correct me if I'm wrong).

    SP2010 -> SP2013 (both upgrade for content DB and Branding upgrade) -> SP2016 -> SP2019

    I do believe that during all this chain, at some point, the upgrade was not executed in a clean way and it left the Content DB in a limbo.
    The versioning in the 1st screenshot about Affected Database Entries are indeed wrong

    1 person found this answer helpful.

  2. Emily Du-MSFT 41,371 Reputation points Microsoft Vendor

    @Bradway, Drew

    I suggest you install the latest CU for the SharePoint 2019 server. Then run following PowerShell.

    PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd installcheck -noinstallcheck  

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

  3. Matteo Zamori 86 Reputation points

    Hi @Bradway, Drew ,

    I have adapted the process based on my previous experiences:

    0 (new): Check and Ensure your Web Application in SP2010 is already migrated/created as Claim Authentication Based
    ---> IF the application is still in Classic Mode Authentication then you have to convert it (
    I recommend you to do this part at the very beginning before moving forward to SP2013. It means you have to do it once as preliminary step in your current production

    1: Copy SP2010 Database to SP2013 SQL Server and attach to SP2013
    ---> Correct (Mount-SPContentDatabase "WSS_Content_XXX" -WebApplication "XYZ" -Confirm:$false)
    ---> Verify your SP2013 is running within SP1 + latest CU applied

    2 (new): Upgrade DB Schema Version to SP2013
    ---> Upgrade-SPContentDatabase "WSS_Content_XXX" -Confirm:$false

    3: Remove any broken Features from all SPWebs
    ---> Correct (Test-SPContentDatabase "WSS_Content_XXX" -WebApplication "XYZ") -- in case you want to take track of possible missing features before removing them

    4 Run Upgrade-SPSite on all sites in Database
    ---> Correct (Upgrade-SPSite -identity "http://XYZ" -VersionUpgrade) -- depending on the number of site collections you can create a foreach loop

    5 (new): Verify the sites are functional and no major issues when browsing them in SP2013
    ---> This is important because you have done already few important steps: Claim Auth Based - DB Upgrade - Site Col Upgrade so it's important you verify everything is under control
    ---> You may check already at this point the DB Version in the SQL Table. You should see something like 15.0...

    6: Detach from SP2013, Attach to SP2016
    ---> Correct

    5: Move-SPSite to new/known good SP2016 Databases
    ---> Not Needed: IF everything OK, at this point, you should simply take another SQL Backup and restore the *.bak files in SP2016 as you did previously
    Once restored then perform again a Mount-SPContentDatabase as you have done in the 1st jump to SP2013 (there is no need to do the Move-SPSite)

    6: Move new Database to SP2019 SQL Server and attach to SP2019 Farm
    ---> Correct

    7: Run User Migration Script
    ---> Why would you do that ? Are you changing also domain while migrating from a SP platform to another ?

    Last couple of shots:

    • The process above is intended for Content Databases only BUT you may need to migrate as well SP Services like UPSA, MMS, BDC, Search config etc... these need to be taken in account as well
    • Depending on your whole architecture, you may also plan to clean up DB logins in SQL when you are jumping from a SP version to another. This is not mandatory because if you are segregating Services Account x platform SP will add the new DB logins automatically. However in case of troubleshooting you may ended up losing more time because each DB will have maybe 5+ logins and it may confuse you

  4. Matteo Zamori 86 Reputation points

    Concerning the jump from SP2010 to 2013, this is well documented in the article here:

    0 comments No comments