SharePoint 2010 Migration - Change Classic to Claims Authentication

Question

Is it best to change the classic mode to claims authentication on the web application before upgrading the SharePoint 2010 DB to SharePoint 2013? What could break the active SharePoint 2010 web application doing it this way? I was thinking of backing up the SharePoint 2010 DB and restoring to SharePoint 2013 SQL environment, mounting, upgrading and then converting classic mode to claims authentication in SharePoint 2013. Is this possible? The Sharepoint 2010 web application will be active until I get it upgraded in SharePoint 2013 and then SharePoint 2016.

Answer 1

The correct way to do this is as follows.

1. Create a Windows Claims Web Application on SharePoint 2013
2. Copy your 2010 databases to the SQL server for SharePoint 2013.
3. Attach your databases to the Windows Claims Web Application you created in Step 1.
4. Run Convert-SPWebApplication -Identity http://webAppUrl -From Legacy -To Claims -RetainPermissions

You can re-run 4 every time you mount a classic content database to a claims enabled Web Application.

You do not want to modify 2010 as you want that to be a stable source should you need to roll back. Therefor, you do not want to convert 2010 prior to migrating to 2013.

Convert SharePoint 2010 Products classic-mode web applications to SharePoint 2013 claims-based web applications

Answer 2

As per Microsoft best practice, you should set your existing sites in a read only mode before starting the migration process and conversion from classic to claims should be done before migration from 2010 to 2013.

Once you convert it from classic to claims, you cannot convert it back to classic. Custom code which uses windows authentication will not work properly in SP2010 after conversion.

You can convert it from classic to claims authentication either before or after migration process. Conversion after the migration will not cause any issue and your existing 2010 environment will run as it is.

You can create new web application in 2013 with claims mode, mount 2010 classic mode DB to this web application , Use Convert-SPWebApplication to migrate from Classic to Claims for each database that is mounted.

Answer 3

Migrate from SharePoint 2010 to SharePoint 2013 - Step by Step process with the recommendation.

SharePoint migration project planning plays a important role - if you have proper planning in place, the success ration of the migration is more - so plan, plan before the actual migration.

Before the migration prerequisites to be followed in SharePoint 2010 server for successful migration:

Make sure your SharePoint 2010 farm is up-to date: Its highly recommended that you have latest service packs/patches installed on your SharePoint 2010 farm before proceeding with migration. Download Patches/Service packs from: http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx Document your existing SharePoint 2010 environment: -Assess current environment and take an inventory of all customizations. Document farm configuration settings in SharePoint Server 2010

1. Refer this check list: 25 Things to Document before You Start SharePoint Migration. http://technet.microsoft.com/en-us/library/ff645391%28v=office.14%29.aspx
2. You can also use codeplex tool: http://spdocgen.codeplex.com/, http://spsfarmreport.codeplex.com/
3. Use Upgrade Work Sheets: Use upgrade worksheets from Microsoft to document your source environment. Download upgrade worksheets at: http://www.microsoft.com/en-us/download/details.aspx?id=30370

Change the Authentication to Claims: This is very important, it is recommended to do it before the migration however we can do it post migration as well using the Convert-SPWebApplication command - this needs be converted for all content database which was mounted.

Note - If the classic to claim conversion did not happen well migrated sites will be messed up with lot of permission issues - as by default in SharePoint 2013 claim is the default authentication. Claims authentication is the default authentication in SharePoint 2013. Many dependent services (like Office Web Apps) require Claims authentication in SharePoint 2013. So before migration convert your SharePoint 2010 web applications from Classic mode (which is default in SharePoint 2010) to Claims. Technet Reference: http://technet.microsoft.com/library/gg251985 Also, If you have "Forms" authentication, make sure its configured in your target farm before migration.

Cleanup Before Migration - Clean up an environment before an upgrade to SharePoint 2013 - This includes deleting unused sites/site collections, Removing unused features and solutions, Delete orphaned users and sites, Cleanup old document versions, Removing features which are not supported by SharePoint 2013 (such as Web Analytics). Technet Reference: http://technet.microsoft.com/en-us/library/ff382641.aspx

Actual migration steps summary:

1. Create new SharePoint 2013 Farm, Setup necessary configurations.

2. Backup - Restore SharePoint 2010 Content Databases to SharePoint 2013's SQL Sever (or perform a detach-attach process)

   3.Verify content databases by running: Test-SPContentDatabase from the Target SharePoint 2013 farm.

   4. Attach Content Databases to SharePoint 2013 web application by running: Mount-SPContentDatabase

   5. Upgrade Site Collections to move them into SharePoint 2013.

Reference URL:

https://www.sharepointdiary.com/2013/09/migrate-from-sharepoint-2010-to-2013-step-by-step.html

And also refer the below documents for basic tips tricks in the migration project:

https://global-sharepoint.com/sharepoint-2/basic-tips-and-tricks-in-sharepoint-migration-project/

Some key notes in migration project:

1. You may ignore the error or exception from Test-SPContentDatabase command, still your Mount-SPContentDatabase will work.
2. While running the Mount-SPContentDatabase for certain content database – if you get an exception or up to some extend some errors, you can ignore those and continue in further migration, still your migrated site will work fine and in these scenario if you see database upgrade status from central admin, we can see upgrade completed with errors status but we can live with this.
3. After content db migration thru database detach and attach approach – we may see some issues in the migrated master page, css and java script code as a result we may expect some differences in the migrated site look and feel and other css and scripting related issue – this is a general behavior which we need to fix manually even though it is time consuming.