Blog post: 3 minute read
I’m working on a scrum team to migrate an entire organization’s file structure off a shared network drive. There’s likely similar stories playing out across many organizations today – years of accumulated “stuff” you somehow need to parse down and move to SharePoint in a structured and organized way.
Rule # 1 of any SharePoint migration? Clean up the content prior to starting. Although it may be tempting to just migrate exactly what you have (it’s generally quicker in the short-term), you will no doubt pay a heavy price for that decision down the road. The problem may manifest itself in many ways. Here are a few:
- you will have poor search results since there is just too much unstructured content to effectively surface it in a meaningful way.
- replicating the folder structure means you are not taking advantage of some of the excellent content management capabilities in SharePoint.
- nothing set up to be deleted in a timely and automated way means we will end up with years of accumulated “stuff” on a different platform – we’ve effectively moved the problem from a file server to a SharePoint environment.
There are capabilities in SharePoint/O365 to automate the cleanup of content in order to address the accumulation identified above. Why not take advantage of it?
You will need to work with your Information Management(IM)/Records Management(RM) team(s) to implement retention controls on the content where and when it’s required. This not only keeps your organization compliant with any regulations you may need to abide by but it will also help to keep your content relevant and (hopefully) easier to find.
There are numerous options available in SharePoint to apply retention. They are differentiated largely by 2 things: the level at which you want retention defined and the rules that drive the retention. The one you select will depend on how your content is laid out in SharePoint, what type of site it lives in and the level you need to apply retention on. You are well-advised to plan this before starting your migration effort to minimize unnecessary support, maintenance and re-work down the road.
With one exception, the types of retention I discuss in this post do not work in Office 365 Groups. The general approach I’m currently advising for content in Groups is to move any high-value business artifacts out of a Group into a more permanent home prior to deleting the group. In the future, this may change.
Retention at a Document Level
NOTE: These retention policies are at a document level and can only be implemented based on a date that’s on the library or content type. If you want to use a column type other than date, custom code is required. As of the time of this writing, none of these options are available in an O365 Group site with the exception of a Deletion policy.
Document library retention: retention set at the document library level means all documents within the library will fall under the same retention schedule. This option is only scalable if you create a policy via the ‘Content Type Policy Templates’ setting at the site collection level and reference that for any document library in the site collection. Alternatively, you can create a unique retention policy for a specific library however this is not a scalable solution.
Folder level retention: you can set retention at a specific folder level. This is a good option if you have specific folders aligned with your retention buckets. However, if you haven’t turned off folder creation you need to be aware that any new folders added by end-users will not have folder-based retention put on it and it will inherit the document library retention (if you have one). This option is not scalable. You need to go into each folder in all libraries and set the retention. Note: If you have folder level retention in the same document library as document library retention is defined the folder level retention will override it.
Content Type level retention: you can set retention at a content type level allowing this to be re-used everywhere the content type is used. This is a scalable option as you define it once and it can be re-used consistently wherever that content type is used.
Deletion Policy: this type of policy is not recommended for documents in sites having structured data and content types. It is an option to broadly manage the automatic deletion of documents in sites housing unstructured data such as OneDrive for Business sites and team sites. You define these policies in the Document Deletion Policy Center in the Security & Compliance Center of Office 365. As of the writing of this post, the rules allowed for deletion in this type of policy can only be based on either the created date or the last modified date + ‘x’ years/months/days.
Once you’ve defined a deletion policy, it can be assigned to either a site collection template (i.e. all team sites or all OneDrive for Business sites) or a specific site collection.
**On First Release, I was able to add a Deletion Policy to a Group Site although I have not fully tested this. This is still marked as in development on the O365 FastTrack Roadmap.
Retention at a Site Level
NOTE: This is a blanket policy used to cover all content within a site. The policy does not look at individual document dates to drive retention. This is not available for any O365 Group sites.
Site Retention Policy: You can use site policies to help control site proliferation. In SharePoint Online, a site policy defines the lifecycle of a site by specifying when the site will be closed and deleted.
By activating a site collection feature called Site Policy this allows you to create a site policy at the site collection level which can then be applied to any subsites to determine when a site can be closed (automatic or manual) or deleted. When a site is closed it will be trimmed from places that aggregate sites to site members such as Outlook, OWA, and Project Server. You can then determine when a closed site will be deleted and a notification will be sent to site owners in advance of deletion. Owners can postpone the deletion for a specified period of time as well. This type of policy is often implemented in tandem with an automated self-service site creation process to help control site sprawl.
Working closely with your IM/RM teams you should be prepared to share the options available within O365 and help them select the appropriate retention solution so you’re ready for the content when it’s migrated in.
Thanks for reading.
-JCK