One thing we learned during our many migrations from SharePoint 2007 to SharePoint 2010 is not to repeat our mistakes. What do I mean by that? Well, SharePoint 2007 was new to many when it arrived and so was the concept of “Metadata”. I will give some options to consider when migrating because I feel a lot of SharePoint is yet unknown to many.
List Columns vs. Site Columns
Unfortunately, this is a question too often forgotten. There is a very big difference between a List or Library column and a Site column. Across my many adventures with SharePoint, I have often seen customers try to fit all their columns into the Document Library. When I asked them why, the answer was evident to them “because SharePoint allows for metadata to classify our documents instead of folders”. Based on that, many have blindly created columns without looking for other solutions. When customers created list or library columns, they were quick to realize that the columns were decentralized. This meant that they only existed in the list or library in which they were created. What a hassle, every time we created a new list or library which needed to use the same column (ex: Language, Office, Country, etc..) we had to recreate it. If the column needed updating, we had to go to each list or library to update it.
Consider the Site Columns.
In your Site Settings, you will find under “Galleries” a menu called Site columns. This contains reusable centralized columns. Reusable because every list or library in the site where the Site columns are stored and its’ sub sites can use them. What does that mean for you? It means that if you create a column to store as a choice all of the offices, then you can reuse this column everywhere in this site and its’ sub sites as well as update it from a central location. It is also one of the simplest ways to create a lookup column that will look up across sites. More information on that is available here.
When migrating from SharePoint 2007 to 2010 or any other version like Office 365, you should always look at the columns you are using and see if they could be changed into a Site Column instead.
If you haven’t heard about content types before, I strongly recommend you read this short description on Microsoft own site. In my own words, a Content Type is a way of telling SharePoint that you want to organize, classify or identify a type of document in SharePoint. A very common example is “Contracts” and “Invoices”. One scenario is to create two document libraries, one called Contracts the other Invoices. This works fine until someone hears about this and wants it repeated in his or her site, and so does his neighbor. In the end, you find yourself in front of over 200 libraries managed individually but with the same columns and settings. One day, a decision is made to add a column to all contracts to improve search in SharePoint and you find yourself going through each library to apply the changes.
Consider Content Types.
SharePoint allows you to create a reusable definition of settings and give it a name; this is called a Content Type. Typical settings will include columns, retention policies, audit policies, Document Information Panel, workflows, etc. This content type and all its’ settings can then be applied to as many lists or libraries within the same Site Collection. This enables you to create a content type called “Contracts” and one called “Invoices” and apply them both to the same library. Why would I apply them both to the same library? Depending on the requirements, two content types in the same library will allow me to have different metadata based on the content I am looking at. But also apply views or workflows on all of it together.
Consider my Contracts and Invoices. I won’t have the same metadata for both, contracts will need the contract # whereas invoices will need the product or service rendered. However, both will need the client’s name.
In this scenario, I can apply both content types in my library to define these documents clearly into categories with the right metadata. I can also apply a simple view that will group by Client Name and allow me to see all Contracts and Invoices for a given Client. This is only a simple example.
Here is an example of a Content Type you use every day, the one associated to every Task List by default:
Be sure, when you migrate to your SharePoint content to always ask yourself these questions. Are there any columns that I could turn into Site Columns, for reusability? Are there any types of document that I would like to manage as a Content Type in SharePoint? Reuse all of the columns associated to it and its’ settings.
Take advantage of SharePoint’s features before just migrating content over. In the next article we will talk more about the Content Type Hub and considerations you should take when migrating.