Sometimes while we do the SharePoint content database migration thru the detach and attach method – we may encounter with errors. However, if we open the migrated site still it does open and work. Here, I will explain how we can reduce the possibility of getting the error and some basic tips and tricks in migration project.
End of this article we will learn the below:
- SharePoint migration project plan
- Best Practices for a Successful SharePoint Migration or Upgrade
- Quick Tips for a Successful SharePoint Migration Plan
- SharePoint server migration steps
- Step by Step guide to Migrate from SharePoint 2013 to SharePoint 2016
- SharePoint migration steps
- SharePoint migration tool troubleshooting
- SharePoint content database migration checklist
- How to see all running workflow instances in SharePoint 2013.
- Find All InfoPath Form Libraries and lists in SharePoint
- PowerShell script for running Test-SPContentDatabase
- PowerShell script to remove features by ID
- SQL query for listing setup file information
- PowerShell script to remove the webpart by ID
- SQL query to list down web part information
- SQL query to get event receiver information
- PowerShell script to remove event receiver
Even though we get some error during the database upgrade we may ignore them, as this is generally common behavior in migration project.
Even I had also faced the similar kind of issue and figured this out by doing the proper analysis in the source system. One of the key parameter for succeeding the migration project is proper planning and analyzing the source environment. Try to get an inventory from your source system about all custom solution and where (in which sites) these custom features are activated, I am sure from the inventory report you will find there are many features those are not really being used in the source system. So you can clean those unwanted feature from target environment – after running the Test-SPContentDatabase command.
For cleaning up the the features you may use the below PowerShell script(available in the below link):
Sample PowerShell script for running Test-SPContentDatabase:
PowerShell script to remove features by ID:
SQL sample for listing setup file information:
PowerShell script to remove setup files by ID:
SQL query to list down web part information:
PowerShell script to remove the webpart by ID:
SQL query to get event receiver information:
PowerShell script to remove event receiver:
Above code reference URL:
For planing and preparing the check list for content DB migration – you may refer the below content:
The basic steps are as below:
- Prepare detailed inventory of environment
Clean up old environment
- Test content
- Prepare destination environment and analyze new environment configurations
Communicate with users
- Start migration
- Read only mode until migration completes
- Post migration, third party tools and resources
SharePoint content database migration – SharePoint migration steps:
Here based on my personal experience I have listed out the SharePoint content database migration steps in high level:
- Create a new SQL server with SQL high availability group and configure SQL listener.
- Create a new SharePoint farm.
- Configure the service application whatever you had in the previous farm.
- Try to migrate the service application data like Manage metadata service, search service etc..otherwise create these services get those service application data thru database migration.
- Create all new web application in the target farm as many you had in the previous farm.
- Deploy all custom solutions if you have, from previous environment to new environment.
- Configure the alternate access mapping for the all the web applications in the new farm.
- Verify the central administration settings for all pages from CA – by comparing old CA and new CA.
- Verify each web application settings from new CA – by comparing old CA and new CA.
- Verify web config files for each web application from new environment – by comparing old web.config file and new web.config file.
- Verify the IIS settings of each web application by comparing old IIS settings.
- Prepare an inventory for all running all workflows.
- Good to complete all running workflows.
- Prepare an inventory for all infopath forms in source SharePoint.
- Prepare an inventory for all data connection used in the infopath forms.
- Plan the migration over the weekend.
- Announce the users about the down time of the SharePoint.
- While declaring downtime estimate at least 20 percent buffer time for any uncertainty.
- Plan for any other dependent teams like – SQL, networking for their availability.
- Make old farm read only ( all web applications).
- Take all content database backup from old database server and restore in new SQL server thru backup restore or detach and attach process.
- Once confidence with all these verification – start the mounting of content database in the new application.
- During mounting the database we might get some errors some we might ignore, but some errors we might to fix.
- After migrating to new SharePoint environment immediately change the infopoath data connection URL to new URL(target SharePoint data connection URL).
- Then open all the infopath forms which we have generated from source SharePoint.
- Access the sites – and perform all basic testing – do not forget to test permissions.
- If all well – finally change the DNS for all the URLS from new environment – so that it will continue to work with the old same URLS only – in the backend just we need to map the DNS to the new server what we have created.
- Declare go live – I have followed the same steps and it was successful.
- Sometimes, even though we change the data connection correctly from the new SharePoint environment, still we will get the data connection error. Then we need to disable the loopback in the registry. And also we need to verify the layout path in the target SharePoint data connection because layout path in source and target are different. Example: SharePoint 2013 and SharePoint 2016.
- Need to be calm and cool : If we face some uncertain issue which is show-stopper for the migration, we should not be tensed. Generally, when we do the migration within the given down time, people get tensed to deal with troubleshooting. So need to relax and work. 🙂
How to get all infopath forms and workflows from SharePoint web application?
Various types of issues and their descriptions with fixes during running the Test-SPContentDatabase :
- You may ignore the error or exception from Test-SPContentDatabase command, still your Mount-SPContentDatabase will work.
- While running the Mount-SPContentDatabase for certain content database – if you get an exception or up to some extend some errors, you can ignore those and continue in further migration, still your migrated site will work fine and in these scenario if you see database upgrade status from central admin, we can see upgrade completed with errors status but we can live with this.
- After content db migration thru database detach and attach approach – we may see some issues in the migrated master page, css and java script code as a result we may expect some differences in the migrated site look and feel and other css and scripting related issue – this is a general behavior which we need to fix manually even though it is time consuming.
Key takeaways from this article:
- SharePoint migration project plan.
- Best Practices for a Successful SharePoint Migration or Upgrade.
- Quick Tips for a Successful SharePoint Migration Plan.
- SharePoint server migration steps.
- Step by Step guide to Migrate from SharePoint 2013 to SharePoint 2016.
- SharePoint migration steps.
- SharePoint migration tool troubleshooting.
- SharePoint content database migration checklist.
- How to see all running workflow instances in SharePoint 2013.
- Find All InfoPath Form Libraries and lists in SharePoint.
- PowerShell script for running Test-SPContentDatabase.
- PowerShell script to remove features by ID.
- SQL query for listing setup file information.
- PowerShell script to remove the webpart by ID.
- SQL query to list down web part information.
- SQL query to get event receiver information.
- PowerShell script to remove event receiver.