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.
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
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.
Figure:SharePoint will show you an error “Missing Site Templates” that prevents you from upgrading
To fix this issue
- Upgrade your site template’s content files and definition XML file to SharePoint 2013 (refer to SharePoint 2013 default site template for details).
- Package the site template’s content files to map location “ {SharePointRoot}\Template\SiteTemplate ”.
3.Package the site template’s definition XML file to map location “ {SharePointRoot}\TEMPLATE\1033\XML ”.
5.Try to upgrade to SharePoint 2013 UI again.
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.
- 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
-
Solutions must be deployed to the new site collection before the content database is resorted to the SharePoint 2010/2013/2016 server:
- Open SharePoint Central Administration | System Settings | Manage Farm Solutions
- Click on Deploy Solution
- 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.
It is strongly recommend to run a pre-migration check on the SharePoint content database before attaching it to trigger the migration process.
Assumptions:
- You have already installed the customized wsp package you know
- You have restored the content database to SQL server
- You haven't attach the content database yet
Steps:
- Run SharePoint PowerShell Console as administrator
- Run the command below
Test-SPContentDatabase - name WSS_Content_DB - webapplication http://sitename
- Check the output log, ensure there isn't any errors
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:
- Backup databases of SharePoint 2010 or 2013 Service Application.
- Restore and attach databases to SharePoint 2013 or 2016 SQL server.
- Create service application in SharePoint 2013 or 2016 Central Admin site with the restored database.
- Test.
- Done.
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 ):
- Open SharePoint Central Administration site, navigate to "Application Management " | "Site Collections " | " Configure quotas and locks ".
- Select the "site collection" which you would like to lock.
- Choose "Read-only (blocks additions, updates, and deletions)", then click "OK". Note: Read more at Manage the lock status for site collections in SharePoint 2013 Option 2 ( not recommended ):
- On your database server open SQL Server Management Studio
- Right click on the content database associated with the site collection you're migrating | Properties
- Choose Options | Scroll to the bottom of the options list
- For the Database Read-Only choose True
- 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
After the database has finished being attached to the web application you will get a log file with information about the import process.
-
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.
- 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
-
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)
- Test Migration
- Install required WSP packages in 2016
- Test migrating content database from old to new
- Fix all the missing customizations error in the above step, then do the content database migration
- (Optional) Migrate services database (depends on which service applications do you use)
- Post migration setup
-
Configure search
- Configure metadata (optional)
- Test test tes t
- Go-live migration
- Put old SharePoint into read-only
- Refresh content & service database from SP 2013 to 2016
- Update DNS
- Decommission old SharePoint server and database (after 2 weeks when you're confident with the new environment)