SharePoint Migration 2010 to 2013

Introduction

This document aims to discuss the overall process of SharePoint migration 2010 to 2013. So the first question is: Why it is necessary to upgrade SharePoint 2010 to 2013. The reason is: there are so many stunning features which can add more value than 2010 to your organizations.

• The Design Manager
• Device Channels
• HTML5, CSS3 and all that good stuff
• Community Sites and Community Portal
• The new Search experience and what it means
• Content Search Web Part
• Apps and the App Store
• WCM Web Content Management

Please note that this is my personal experience with migration. All scenarios may not match with your environment. In that case, you have to plan very carefully.

Planning

Planning is very much important in migration. In the very beginning, you have to analyse your existing SharePoint 2010 farm. Please do note down everything. I have done the following things in my case.

• SQL server version
• Number of web applications
• Number of service applications
• Number of features in each web application
• Number of custom solutions (farm & sandboxed)
• Hardware & Software
• Authentication provider

Based on the existing farm, you have to prepare a new farm for SharePoint 2013.

Migration Process

The official ^[1] words for SharePoint migration are as given below:

The database-attach method is the only supported method for upgrading from SharePoint 2010 Products to SharePoint 2013

Migration Steps

I hope your new farm (2013) is ready as per your planning. Now, we need to follow the below steps for migration:

1. Database backup from old server
2. Database restore in new server
3. Create new web application
4. Remove content database from
5. Test content database
6. Mount database
7. Add & Install custom solutions
8. Upgrading sites
9. User Migration

Database backup

It is the very first step of migration. Database backup can be taken in several ways like command line, using management studio, etc. I always prefer command line. Before taking the database backup, set the database to read-only mode.

"C:\Program Files\Microsoft SQL Server\110\Tools\Binn\osql.exe"
-E -Q "BACKUP DATABASE '{database name}' TO DISK='{path}' WITH FORMAT" 

• {database name} is the name of your content database. Example: ‘WSS_Content’
• {path} is where you want to save the backup file. Example: ‘C:\db_back\sp_2010.bak’
• Don’t forget to change SQL version number. In my case, it was 110.

Database Restore

Now login to your new database server. You can restore old database using query or UI from Management Studio. If you want to it using UI, then follow these steps from MSDN. Using query window, just open the query window in your management studio, then paste the following query & execute it.

RESTORE DATABASE '{new database name}' FROM DISK = '{path}'
WITH REPLACE, RECOVERY,
MOVE '{old database name}' TO '{new mdf path}',
MOVE '{old log name}' TO '{new log path}'

• {new database name} is the name of your new database. Example: ‘WSS_Content_Migrated’
• {path} where your backup file is located. Example: ‘C:\sp data\sp_2010.bak’
• {old database name} is the name of your old database. Example: ‘WSS_Content’
• {new mdf path} where you want to save new mdf file. Example: ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\WSS_Content_Migrate.mdf’
• {old log name} name of the old log file. Example: ‘WSS_Content_log’
• {new log path} where you want to save new log file. Example: ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\WSS_Content_Migrate.ldf’

Now wait till script execution is done. Again, do not forget to change all parameters in query.

Create New Web Application

After successfully restoring your content database, login in your SharePoint 2013 server. Now, you have to create a new web application where all site collections will be restored. It is recommended to use the same host header as an old web application in 2010. You can do it from central administration or PowerShell. Following is the PowerShell command for creating a new web application.

New-SPWebApplication -Name {Name} -ApplicationPool {ApplicationPool}
-AuthenticationMethod {WindowsAuthType}
-ApplicationPoolAccount {ApplicationPoolAccount} -Port {Port} -URL {URL}

• {Name} is the name of the new web application. Example: “SharePointPlex Intranet Portal”
• {ApplicationPool} is the name of the application pool. Example: “SharePointPlex Pool”
• {WindowsAuthType} is either “NTLM” or “Kerberos”. Kerberos is recommended.
• {ApplicationPoolAccount} is the user account that this application pool will run as. Example: (Get-SPManagedAccount “domainName\userName”)
• {Port} is the port on which the web application will be created in IIS. Example: 80
• {URL} is the public URL for the web application. Example: portal.sharepointplex.com

Remove Content Database

If your new web application is associated with a content database, then you need to detach/remove that database from your web application. Again, you can do it from central administration or PowerShell.

To detach database only, you can use the following command:

Dismount-SPContentDatabase "{ContentdBName}"

• “{ContentdBName}” is the name of your content database

To remove database permanently, you can use the following command:

Remove-SPContentDatabase "{ContentdBName}"

• “{ContentdBName}” is the name of your content database

Test Old Content Database

In this step, we need to test old content database with our new web application to verify all customization referenced within the old content database. It will give us a complete report of customization and services activated in the content database. It is better to export the logs in a CSV file for better visibility. Now, run the following command to test your content database.

Test-SPContentDatabase -Name '{database name}'
???????-WebApplication {url of web application} | Out-File {log path}

• {database name} is the content database. Example: ‘WSS_Content_Migrated’
• {url of web application} is the url of new web application. Example: portal.sharepointplex.com
• {log path} where you want to save log file. Example: ‘C:\log\test_database_log.csv’

Now open ‘C:\log\test_database_log.csv’ and based on that, do some troubleshooting. This log file does not contain the issues only. It will give you some suggestions as well.

Attach Old Database

If you are done successfully with the above steps, then it’s time to attach the old database with the new web application. To do this, you can run the following command.

Mount-SPContentDatabase {database name}
-DatabaseServer {database server name}
???????-WebApplication {web application url} -AssignNewDatabaseId

• {database name} is the name of your content database. Example: “WSS_Content_Migrated”
• {database server name} is the name of database server. Example: “SRV-DBSQL12”
• {web application url} is the url of your web application. Example: portal.sharepointplex.com
• Please note that -AssignNewDatabaseId is very important. This will allow the New Database to be attached to the farm without a conflict of Database Id.

You may get the following error in this step but do not worry about it. Just open the log file and troubleshoot according to it.

Mount-SPContentDatabase : Upgrade completed with errors. Review the upgrade log file located in
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\
LOGS\Upgrade-20151230-173217-657.log.
The number of errors and warnings is listed at the end of the upgrade log file.
At line:1 char:1
+ Mount-SPContentDatabase "WSS_Content_Migrated" -DatabaseServer "SRV-DBSQL12" -We ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Share...ContentDatabase:SPCmdletMountContentDatabase) 
[Mount-SPContentDatabase], SPUpgradeException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletMountContentDatabase

Add Custom Solutions

In this step, you need to add all your custom solutions which have been developed using Visual Studio 2010. If you are sure that your custom solutions will work without up-gradation, then you can add them using PowerShell directly.

Add-SPSolution {path of the solution}
Install-SPSolution –Identity {solution name}.wsp –WebApplication {web application url} -GACDeployment

If your solutions contain third-party libraries, then up-grade them using Visual Studio 2013 and finally add them in your web application.

Upgrade Sites

Now login to your site. You should get the same interface as SharePoint 2010. So it’s time to upgrade your sites. In the header of your site, you should get the following notification:

Now click on the Start now link, then the following screen will appear.

If you click on Upgrade this site collection, It will ask for your confirmation.

Now confirm it and wait until it is done!

When everything is done, you should get everything as SharePoint 2013.

User Migration

Once you are done with site up-gradation, then you have to migrate your SharePoint users. If there is a change between your authentication model, then this step is needed. Basically, you have to change the prefix of all SharePoint users. To do that, you can take help of my following scripts.

$web = Get-SPWeb {web application url}
$userName = {user name}
$OlduserID = '{domain name}\' + $userName
$newuserID = 'i:0#.w|{domain name}\' + $userName
$user = Get-SPUser -Web $web -Identity $OlduserID
If($user) {
$newuserID = $web.EnsureUser($newuserID)
Move-SPUser -Identity $user -NewAlias $NewuserID -Confirm:$false -IgnoreSID
Write-Host $employee.UserName + " Migrated"
} Else{
Write-Host $employee.UserName + " unable to migrate"
}

In my case, the old user was like:

sharepointplex\atish

After migration, it looks like:

i:0#.w|sharepointplex\atish

NB: My domain name was sharepointplex.

Conclusion

I wish your migration has gone very smoothly. If it does not, then feel welcome to contact me via the comments section below. I will try to reply within a short time.

Reference

1. SharePoint 2013 Upgrade Process: https://www.microsoft.com/en-us/download/details.aspx?id=30371