Summary: Moving away from Fileshare to SharePoint is one of the most painful exercises most organizations describe. With the structured approach, you can simplify this process to just few workshops and end up with rock solid, and easy to find structure. Avoid using existing folder names as your new SharePoint structure and simplify existing containers first before defining metadata.
Although we’re builders of intranet-in-a-box, we often consult on the SharePoint migration projects. One of the most common challenges in any organization using fileshare, is migrating this old structure to SharePoint. Even with a wealth of tools available in SharePoint around content findability, such as metadata and tags, you need input is required from your teams.
So, how do we go about it in just few simple workshops?
First, you’ll need to bring the right people to the table.
Here are few guiding principles:
Understand which teams own content in your existing fileshare
Ideal group size is 4-6 stakeholders
Ensure people in the room are content owners, and members who can assign tasks and allocate resources for their team. This doesn’t have to be the same person, hence we recommend 4-6 people per team.
Ensure everyone in the room is likely to contribute for their area and not just listen in.
You have picked the right people, now onto the content audit.
First, why do we need content audit? Don’t we already know what content is in our fileshare?
Our experience shows the following:
Not everyone on the team knows everything about their existing fileshare structure
Much of the structure is obsolete, ad-hoc, with lots of catch-all folders
Every workshops we ran, had people discover something new about the content based on their peer’s input
Running the workshop (in person)
Request for participants to individually write down types of content their own and work with.
Give examples, such as: project status report, project plan, risks and issues etc. This will help ideas flowing
Ensure participants work individually.
Request each participant to share their individual types of content and let others ask questions
Keep other participants interaction only for clarifications, not brainstorming, countering, or questioning workflow or business flow. There will be separate activity to cover that :)
More often than not we work with hybrid teams where some participants are at the office and others are remote. There are facilitation techniques we use to accommodate this, which is a whole different topic, and with the right mix of technology and facilitation participants as as productive as in on-site meeting. The key to remote session is preparation and make sure everyone can contribute without feeling left out.
As a result you will end up with a sample structure like below. And by the way, with all the pre-work to get to this point will only take about 45 min with an experienced facilitator.
Defining New Content Structure
Now that we have all the content on the table and everyone has the context of what everything is, it’s time to shape this into a tree.
The task is to: group relevant content into logical groups or clusters and assign labels to each cluster. For example: [Contract Template], [Agreement Template], and [SOW Template] can be collectively put into category called [Templates].
Towards the end of this exercise you will end up with something like this, notice how various content types cluster around themes forming what we call SharePoint Content Type:
At this point we spent only about an hour and 1/2 and already have a good idea how the new repository will look like. Next, we finalize the structure.
Selecting Metadata and Tags
With the metadata you can group content by any number of tags, virtually creating “folders” on the fly. With the folder, you get to navigate the structure in a fixed format.
Regardless of method you chose to structure your content, folder or metadata, using the output from the previous exercise, it’s easy to build the final structure.
Here are some guiding principles when tagging your content:
Use auto-tagging feature in SharePoint to tag content automatically when it’s dropped into a specific library or folder (if you chose to go with folders).
Avoid creating hierarchies deeper than 3 levels. For example: [Project Alpha] -> [Deliverables] -> [Fact Sheet] is a good example of 3 level hierarchy.
Avoid manual versioning and creating folders to manage those. For example, avoid: Contract_v3_final, instead rely on built in versioning features to version your content.
This may sound like nothing to do with the metadata but we often see people create folders for Draft/Final documents which affects content structure
Don’t confuse Metadata with a Document Type. This might sounds obvious but people make this mistake all the time. Consider this scenario:
Should [Balance Sheet] be a content type or the [Year]?
The correct way is [Balance Sheet] as a Content Type since and [Year] is a Metadata field.
NOTE: Content Types reflect entities around which rules are formed (archival, retention etc). Metadata, in this case [Year], is merely a descriptor/property of the entity.
As obvious as it is, many fileshare structures out there have the exact opposite in how folders are structured.
When we follow this collaborative approach with the client we see huge increase in adoption and decrease in support. The tempting alternative of bringing structure from fileshare will bring old problems to the new environment. We have used this approach on number of projects over the years and refined it meticulously for the best results, so if you have questions about details - drop us a note!
What are some of the challenges you found when migrating from fileshare to SharePoint? Leave your comment below.
Yaroslav Pentsarskyy is the Director of Product at Origami. He's also 8 time Microsoft MVP, speaker at many local and worldwide tech events, and a published author of several SharePoint related books.