SSW Foursquare

Rules to Better SharePoint Migration from 2010 to 2013 - 9 Rules

Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see.

If you still need help, visit SharePoint Server Consulting and book in a consultant.

  1. Do you have a SharePoint Master?

    You all know about a web master, the central point of contact if the website goes down. You should know about Schema Masters for Database Design. SharePoint should be no different.

    The SharePoint master should be your companies SharePoint expert. All major changes to the SharePoint servers should be run by the SharePoint master including:

    • Deploying or removing solutions and features
    • Creating web applications
    • Migrations
  2. Do you know that you need to migrate 'custom site template' before upgrade to SharePoint 2013 UI?

    If you have “custom site template” for your site, you can’t upgrade your site to the SharePoint 2013 UI unless you have a site template with the same name ready for new UI.

    missingSiteTemplateError

    Figure:SharePoint will show you an error “Missing Site Templates” that prevents you from upgrading

    To fix this issue

    1. Upgrade your site template’s content files and definition XML file to SharePoint 2013 (refer to SharePoint 2013 default site template for details).
    2. Package the site template’s content files to map location “ {SharePointRoot}\Template\SiteTemplate ”.

    siteTemplateStructure

    3.Package the site template’s definition XML file to map location “ {SharePointRoot}\TEMPLATE\1033\XML ”.

    siteTemplateDefinitionFile 4.Deploy the package.

    5.Try to upgrade to SharePoint 2013 UI again.

  3. Do you know how to identify customizations on SharePoint webs?

    To do a successful migration, you must find all the customizations in your current environment.

    • Use command stsadm.exe -o enumallwebs -includefeatures -includewebparts \>C:\checkcustomizations.txt to list all the features and webparts on webs.

      1. Run this command on both your current Production environment and Test migration environment to get the list of features and web parts. GetCustomFeaturesAndWebParts
      2. Use text comparision tool, such as BeyondCompare or WinDiff, to compare your Production envionment to your Test migration environment list to identify custom features and web part.
    • Go to Central Admin site to check which custom WSP package has been deployed

      1. Go to Central Admin site | System Settings | Manage farm solutions, to look for deployed custom solution package. CustomSolutionPackages
      2. Compare web.config files between Production and Test environment as well to identify custom controls.
  4. Do you know how to deploy the imported solutions to the new site collection

    Solutions must be deployed to the new site collection before the content database is resorted to the SharePoint 2010/2013/2016 server:

    1. Open SharePoint Central Administration | System Settings | Manage Farm Solutions
    2. Click on Deploy Solution
    3. Refer to the table you completed in the rule Do you confirm your list of installed Solutions and deploy the solutions to the same site collections they were deployed to on the SharePoint 2007/2010/2013 server.
  5. Do you run Test-SPContentDatabase before migration

    Assumption:

    1. You have already installed the customized wsp package you know.
    2. You have restored the content database to SQL server
    3. You haven't attach the content database yet.

    It is strongly recommend to run a pre-migration check on the content database before attaching it to trigger the migration process.

    Steps:

    1. Run SharePoint PowerShell Console as administrator
    2. Run the command below
    Test-SPContentDatabase - name WSS_Content_DB  - webapplication http://sitename
    1. Check the output log, ensure there isn't any errors.
  6. Have you migrated your service application databases

    Depends on your SharePoint farm environments, you may need to upgrade some service applications databases.

    In our case, we have upgraded the below several service application databases:

    • Secure Store
    • User Profiles
    • Managed Metadata
    • Business Connectivity Services

    Steps:

    1. Backup databases of SharePoint 2010 or 2013 Service Application.
    2. Restore and attach databases to SharePoint 2013 or 2016 SQL server.
    3. Create service application in SharePoint 2013 or 2016 Central Admin site with the restored database.
    4. Test.
    5. Done.
  7. Do you lock the SharePoint Content Database before making a backup?

    Even though you have advised staff members a migration is taking place – you can guarantee someone will try to check-in or edit documents. The best way to prevent this is to put your content database into read-only mode, locking the content database.

    There are two options to lock the content database.

    Option 1 ( Recommended ):

    1. Open SharePoint Central Administration site, navigate to "Application Management " | "Site Collections " | " Configure quotas and locks ". quotas and locks
    2. Select the "site collection" which you would like to lock.
    3. Choose "Read-only (blocks additions, updates, and deletions)", then click "OK". read only status Note: Read more at Manage the lock status for site collections in SharePoint 2013 Option 2 ( not recommended ):
    4. On your database server open SQL Server Management Studio
    5. Right click on the content database associated with the site collection you're migrating | Properties
    6. Choose Options | Scroll to the bottom of the options list
    7. For the Database Read-Only choose True

    LocLSQLDB
    Figure - Database Properties | Options | Database-Read Only

    1. Now it’s safe to take a backup of your content database

    NOTE: When some SharePoint timer services are run it may cause the site to display errors when the database is in read-only mode

  8. Do you check for errors after the migration process?

    After the database has finished being attached to the web application you will get a log file with information about the import process.

    1. Open up this log fine and pay special attention to any lines with [ERROR] .

      Note #1: The most common reason for errors is that you have forgotten to activate a feature.

      Note #2: If you have your own custom solutions, show this file to your developers to ensure it isn’t your custom solution causing the errors.

    2. Check your Application Event log after migration for errors related to your SharePoint Web Application, and fix these accordingly.

    FixEventLogs

    figure: the event log should show 0 errors after fixing the errors

  9. Do you have a migration plan

    At a high level, the plan is:

    • Install SharePoint
    • Install with topology of your choice in SharePoint 2016 (or use AutoSPInstaller)
    • Configure Application services
    • Run the wizard (or use script. the community script wasn't ready when Thiago and I was migrating intranet)
    • Configure user profile and its permission configuration (see msdn)
We open source. Powered by GitHub