Rules to Better SharePoint Migration from 2013 to 2016

​​

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!

  1. Do you have a migration plan

    ​​​At a high level, the plan is:

    • Install SharePoint ​
    1. Install with topology of your choice in SharePoint 2016 (or use AutoSPInstaller)
    2. 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​)​
    • Test Migration
    1. Install required WSP packages in 2016
    2. Test migrating content database from old to new​
    3. Fix all the missing customizations error in the above step, then do the content database migration
    4. (Optional) Migrate services database (depends on which service applications do you use)
    • Post migration setup
    1. Configure search
    2. Configure metadata (optional)
    • Test test test
    • Go-live migration
    1. Put old SharePoint into read-only
    2. Refresh content & service database from SP 2013 to 2016
    3. Update DNS
    4. Decomm​ission old SharePoint server and database (after 2 weeks when you're confident with the new environment)


    Read more about Do you have a migration plan

  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.
    1. Run this command on both your current Production environment and Test migration environment to get the list of features and web parts.GetCustomFeaturesAndWebParts.jpg
    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.jpg
    2. Compare web.config files between Production and Test environment as well to identify custom controls.
    Read more about Do you know how to identify customizations on SharePoint webs

  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 th​e 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 admini​strator
    2. ​Run the command below​​​​

      ​​​​Test-SPContentDatabase -name WSS_Content_DB -webapplication http://sitename​

    3. Check the output log, ensure there isn't any errors.
    Read more about Do you run Test-SPContentDatabase before migration

  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.

     
    Figure - Send your staff an email warning of the outageDo 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.jpg

    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.jpg
    Note: Read more at Manage the lock status for site collections in SharePoint 2013
    ​​

    Option 2 (not recommended):

    1.    On your database server open SQL Server Management Studio

    2.    Right click on the content database associated with the site collection you're migrating | Properties

    3.    Choose Options | Scroll to the bottom of the options list

    4.    For the Database Read-Only choose True

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

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

    Read more about Do you lock the SharePoint Content Database before making a backup?

  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.

    Read more about Have you migrated your service application databases

  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.

     
    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


    Figure: Do you have a SharePoint master