Using Sharegate to archive obsolete SharePoint sites

During SharePoint migration projects, you might end up with some content -either complete sites or lists- which isn’t used anymore. What to do with this obsolete content?

At one of my clients, we were required to archive obsolete SharePoint sites. These were mostly closed project sites and were hosted in a SharePoint 2007 environment. The requirements were to save this content for at least seven years, not to migrate the entire SharePoint 2007 sites and to make the content accessible to users (if needed).

Archiving options

Ok. Based on these requirements I had several options. But I do like to be complete, so I looked at some other options as well. Let’s go.

Don’t archive

Deleting the content is the easy way out. And if you don’t have any requirements for holding on to your content, be my guest 🙂 But in my case, I had the requirement to archive the old content. So we’ll skip this on.

Back-up the content database(s) of the SharePoint 2007 environment

This might have been an option some time ago. Just back-up the databases and if needed, restore them. My main problem with this option is that it’s not future prove. We cannot guarantee that the data can be restore or accessed in (let’s say) seven years from now. And if we need to restore it, where do we restore this to? A SharePoint 2007 environment?

Two other reasons why this option wasn’t valid is that it would contain all content from the SharePoint 2007 environment. And we don’t need all that content. And, more importantly, the end-users would not be able to access the content.

Export all content and store it on a file-share

This might be a solution. Export the required content to a file-share and delete it after the retention period. The problem with this option is twofold. First of all, the file-share would not be readily available to end-users. The other problem is the retention period. You can use Windows Server 2012 to set retention periods on stored files (https://technet.microsoft.com/en-us/library/hh831826(v=ws.11).aspx). But my client isn’t using Windows Server 2012 and wasn’t planning to use retention on files stored on Windows servers. So this option became obsolete.

Migrate all sites to SharePoint Online and use site-policies

This might be a smart move. Just migrate all content to SharePoint Online and don’t differentiate between used and non-used content. I considered this option. We could just migrate the obsolete sites (one-on-one) to SharePoint Online and use a specific term in the URL (for instance) to show that this site was an archived site. We could also use site-policies to store the site for seven years and then delete it permanently.

In the end, this option was discarded. For one, this option would take a large chunk out of our SharePoint Online environment. We would also have to create some sort of search and navigational structure for the archived sites. And, more importantly perhaps, would the end-user be able to differentiate between these archived sites and the new sites?

Use the SharePoint Online record center

What if I could store the content in the SharePoint Online record center and use record management policies to govern the disposal of the content? The record center was open to all users (readable and not for confidential content) and ready for use.

But where do you store the content of a SharePoint 2007 site-collection? I only needed to store the content, not the site structure as-such. So I came up with one solution: an archive documentset.

For every SharePoint 2007 site-collection, we would create an archive documentset which will contain specific metadata. For example:

• the date of archiving;
• the original URL;
• site-title;
• the original owner of the content.

The archived content will be stored in folders within the documentset. And it will need to be easily accessible. So it will look something like this.

With a quick reference chart, we could easily explain this to the original owners of the content.

Metadata????

But now for the hard part. One of the business requirements was to save the metadata and preserve all versions of documents. A manual export (using something like the Windows explorer) would not be sufficient. So in the end, I started to look at the export/import functions of Sharegate.

Sharegate

I’ve known Sharegate for some time. But I was under the impression that the Sharegate tooling could only be used for “proper” migration scenario’s. Stupid huh? But using a trial license for only a couple of minutes, I became convinced. This was the exact tool we needed. Sharegate comes with an export/import function. You can select which content you want to export. This can be the entire site-collection or any part of the site-collection (subsites or lists).

We used the Sharegate GUI to test the export function. But we used PowerShell to automate the procedure. In the end, the export function provided us with a folder structure. But you can have Sharegate provide you with an export without any hierarcy as-well.

Every version of the documents was saved (you can edit this setting) and the metadata was written to an Excel-file. All lists were saved and attachments were stored as well.  Now it was time for the hard part. The export created a folder structure. But we needed an archive documentset. We solved this using the Excel export.

Excel export

Using the Sharegate GUI we exported the migration data. This allowed us to edit the metadata of the exported content. We used this to switch the top-level folder to the archive documentset and to add the required metadata.

Why? Because Sharegate gives us an folder-export. We wanted to create the archive documentsets. By editing this Excel, we were able to let Sharegate do this for us! And not just creating the documentset. Required metadata are added automatically!

Very cool stuff!

Import

It was a very hardworking process, but we finished it in the end. We could now import the content using the modified Excel-sheets. This worked like a charm. In the SharePoint Online record center, archive documentsets appeared. And now, the SharePoint 2007 content is save, until permanently deleted 🙂

Accessing the content

Now that the content was save, we needed it to be accessible. I do need to emphasize that this accessibility was to be a last resort. The record center was not to be used for continuous access to the content or a working environment.

But using the metadata we stored with the SharePoint 2007 archive documentset, we could provide our end-users a way to retrieve the content. We enabled a specific search page, using these metadata as search refiners. The metadata were added to the metadata navigation panel.

And that’s it. I’m kinda proud of this solution as it uses standard SharePoint functions to provide a workable solution for archiving obsolete SharePoint 2007 content.