Background image

SharePoint automation vs migration tools

default post thumbnails default post thumbnails

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.

SharePoint automation vs migration tools

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.

Interested in reading more on the subject? Check out this article on how you can Schedule your SharePoint migration using PowerShell and Sharegate



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.

Recommended by our team

What did you think of this article?

Live Webinar Join us on February 22 for the unveiling of the new ShareGate experience.