SharePoint Automation vs Migration tools
I am developing a solution for my client, Contoso. Recently, he asks me to migrate his old collaboration sites to his new collaboration web application. Seems simple right? Not so much since we are developing custom solutions for different team in the new web application.
Here, the solution’s developer speaking. The best practice in developing a SharePoint solution (webpart, custom lists, etc) is to be able to deploy the whole site structure anywhere at any time.
Obviously, we want this structure to be the same all the time. So we opted for automation.
Automate with PowerShell
I’ll explain: we wrote PowerShell scripts that recreate the site collections with the same content database name, same site template, same administrator, etc. This gives us, developers, consistency on the deployment. We have to replicate the client architecture and to have the exact same architecture is crucial. So by creating an automated system to recreate our structure, we are basically guaranteed to have the exact same site collections and sites with the proper security and databases.
Here is how you can quickly automate the recreation of your solutions between environments using PowerShell:
The xml file (input.xml) look like this :
And I simply call like this :New-SiteStructure ./input.xml
But then, we have no content in the SharePoint lists and libraries.
Before Sharegate, we use to develop “drivers”. Developers reading this might know what I’m talking about.
I developed a small application (I could do it with PowerShell too) that uses the Client Side Object Model of SharePoint to move list items from one list to another. I remember clearly that I used to run those “drivers” in debug because there was always something wrong.
Figure 1 : Old migrator tool made for transferring content for a customer.
Migration tools to the rescue!
Now, with Contoso, Sharegate is an essential tool for all the solutions that I develop.
The reality is that you often develop a solution for a customer that replaces an old one. It’s mandatory that your service includes the migration of his SharePoint content. So we use Sharegate to put their content in quality assurance and production.
The point I want to bring with my little story here is that there is a time to code and there is a time to use the tool. I believe that the structure of a solution must be automated to enforce consistency but the content migration doesn’t have to be automated. I save time, time that I invest in developing better SharePoint solutions.
Tip: when moving a large amount of data, use Sharegate on the SharePoint server directly, so it doesn’t have to write through the network. I know, it’s a client operation and doesn’t need anything installed on the server but we gained in performance for our scenario.
- The Just Damn Simple Video Series!
- Top 15 Reasons to Migrate to SharePoint 2013
- 5 Effective SharePoint Migration Tips
- Top 10 SharePoint Articles of 2013 and a look back by Benjamin Niaulin
- SharePoint Migration now up to 10 times Faster with Sharegate 4.4
- Not Just SharePoint Migration - 10 Ways to use Sharegate Day to Day