Rules

Secret ingredients to quality software

Edit
Info

Rules to Better SharePoint Migration from 2013 to 2016

9 Rules

  1. 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)
  2. 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.
    • Run this command on both your current Production environment and Test migration environment to get the list of features and web parts. GetCustomFeaturesAndWebParts
    • 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
    • Go to Central Admin site | System Settings | Manage farm solutions , to look for deployed custom solution package. CustomSolutionPackages
    • Compare web.config files between Production and Test environment as well to identify custom controls.
  3. 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.
  4. 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.
  5. Do you advise staff members you are about to perform a migration

    Email the staff members advising a migration is about to take place and they will not be able to check in or edit documents, and should expect errors if they do so.

    OutageEmail Figure - Send your staff an email warning of the outage Do you know how to send a good network outage email?

  6. 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

  7. 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.
  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 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

    JohnLiu Figure: Do you have a SharePoint master

We open source. This page is on GitHub