Wednesday, February 5, 2014

Migrate SharePoint 2010 content databases to SharePoint 2013

Migrating content from SharePoint 2010 to SharePoint 2013 normally performed as a two step process.

In this post I’ll present high level steps to migrate a SharePoint 2010 content databases to SharePoint 2013. This will be the first step of our SharePoint farm migration

1. Plan for downtime and communicate to users

We need to make content databases read only in SharePoint 2010 environment which is the production version at the moment. It’s important to notify users about the maintenance activity and establish a maintenance window

2. Setup SharePoint 2013 farm

SharePoint 2010 supports In-Place upgrade as well as Database attach upgrade methodologies to upgrade from SharePoint 2007 to SharePoint 2010. But SharePoint 2013 supports only the database attach method. Because of that we need to setup a new SharePoint 2013 farm.

We need to configure service applications as well. We can migrate certain service applications as well (e.g. Managed Metadata Service) . But in this post I’ll not going to talk about service application migration. You can read an overview of service application upgrade by referring to this post

3. Create web application in SharePoint 2013 farm

Creation of web applications is straight forward. But the approach changes if our SharePoint 2010 farm uses classic mode authentication. If that is the case we need to follow the steps given below

a. Create web application using classic mode in SharePoint 2013

  1. $acc = Get-SPManagedAccount "dev\spserviceapp"
  2. New-SPWebApplicationname "Web App"Port 8081ApplicationPool "ClassicAppPool"ApplicationPoolAccount $acc

b. Follow all the steps given below (4 to 7) and convert the web application to use claims based authentication

  1. Convert-SPWebApplicationIdentity "http://sp13:8081"To Claims -RetainPermissions -Force

4. Backup and Restore content databases from SharePoint 2010 farm to 2013 farm

Let’s assume we have a medium or large SharePoint 2010 farm. Most probably there will be more than one content database in our web applications. It’s better to backup and restore one database at a time to make other databases available for read/write operations.

Before take the backup we make the content database read only. It is important to note that we keep it as it is until the migration complete. This is because we need to avoid users adding new content during the migration period.

image

Then we’ll copy databases to SharePoint 2013 environment and attach them in SQL Server.

image

If our web application contain multiple content dbs, we need to attach the content db which contains the root site collection first.

5. Setup server side customizations

Before we mount the database to the web application, we need to deploy any customizations(e.g.: site definitions, web parts, etc..) those are being used by sites. It’s important to note that, those customizations ( wsp packages) will be deployed to 14 hive by default.

It’s better to upgrade customizations using newer features in .Net framework 4.5. But for the time being we will deploy same packages and upgrade them later. We’ll discuss that point in a our next post

6. Test the content database to identify missing components

We can use Test-SPContentDatabase command to check if there are any further server side customization to deploy in SharePoint 2013 environment

image

7. Upgrade content databases

Finally we will mount the databases to web application using Mount-SPContentDatabase command

image

This will successfully migrate sites as shown below. As you can see site collections still hold the SharePoint 2010 look and feel. I’ll explain the steps to upgrade those sites to SharePoint 2013 mode in a separate post 

site12

8. Test migrated sites

It is always better to verify migrated sites prior to UAT. If there are too many sites, it’s possible to take a sample site set (e.g. 20%) from each content db for the test. We need to focus on following areas when doing the test

  • Service applications (e.g.: If we migrate or created Managed Metadata Service, test if taxonomy columns, metadata navigation in migrated sites working properly)
  • Server side customizations (e.g.: web parts, workflows, etc..)
  • Missing images, styles and scripts
  • Site count
  • Content count
  • Users and permissions

1 comment:

Anonymous said...

Thanks for sharing the information.

For more info : Software Development Company in Delhi