Deploying a fresh SharePoint environment offers the opportunity to fix and reorganize what might feel like a hodgepodge of content, correcting the sins of your SharePoint past.
A SharePoint upgrade project offers a convenient occasion to face your content challenges—unmanageable structures cluttered with content yet where people can’t find anything useful. Content repositories have a way of evolving, and sometimes how we interact with the content changes. Revising and reorganizing your content from time-to-time is natural and normal.
Throughout my career working with SharePoint, I have worked on these types of content course corrections numerous times, both with environments I managed and consulting clients with their environments. I break my process to approach content migration into five steps:
- Conduct a Content Audit
- Design an Information Architecture
- Plan Content Pruning
- Plan the Content Move
- Execute the Content Migration
Conduct a Content Audit: Auditing your content involves taking an inventory and analyzing what content your organization stores, how complex it is, and how much work it will take to move it to the new system. I start by looking at aggregate information and then analyzing details where I need more information. This approach to progressively refine details helps, because often there isn’t budget or time to do a thorough audit of every piece of content within an organization. Thus, I have to generalize, infer, and estimate much of the content details.
In a content audit, I consider the following questions as I probe to understand the organization’s content:
- How much storage space does each content repository consume?
- How many files does a repository store?
- What file types does a repository contain? (Some files like Word are idea for SharePoint, while others like AutoCAD drawings might be more appropriate for a product like Vault Server.)
- What folder and file names do people use in the repository? (This can identify the type of content usage as well as potential metadata to capture.)
- How deep is the repository’s folder hierarchy?
- What is the age range of the repository’s files? (You could look at the oldest and newest file date.)
- How frequently do people access the repository?
- What groups or departments use each storage repository?
- Who has access and security permissions to the files?
- Do files always live in a repository, from creation to archival to disposal, or do they come from or go to other repository locations?
The answers guide the rest of your content migration planning. For example, you can use the answers to identify the different repositories that a group stores its content in and then determine if you want to consolidate the content and redesign its information architecture.
Design an Information Architecture: Having a good understanding from the content audit of how people store and use their content can offer you fresh insights into ways you can reorganize and improve future relevance. SharePoint might offer new features such as organizing content by metadata from an enterprise taxonomy. Or previous organizing assumptions may have since changed. Whatever the reasons, now is the perfect time to rethink how to make content more relevant and more available to people.
Plan Content Pruning: Not all content provides value to your organization, and hoarding unnecessary content on the off chance you might need it “someday” is wasteful and costing you. One way unneeded content costs you is having it clutter up your repository, creating noise and obscuring relevant and valuable content. Look at what content you can purge and design a plan to do so rather than carry these issues forward to the new SharePoint environment.
Plan the Content Move: Moving content between systems can involve using specialized tools, particularly if there is a lot of reorganizing or tagging or some other intervention that can be automated to better structure and manage the content in the new environment. You can also migrate content manually where your team rolls up their sleeves and start moving and cleaning up content one repository at a time. Obviously this wouldn’t scale well, and that’s where the tools come in. I like to consider both approaches and decide the best mixture to meet the project needs and constraints.
Execute the Content Migration: No migration tool is perfect—there is no easy button to do much of the content cleansing work with confidence. Some things fit a rule well, but a lot of others require human judgment to make decisions. This effort investment will lead to better organized content that you can migrate or upgrade easier in the future.
When your content is already organized (or you don’t want to or don’t have the budget to reorganize it), you can just do a bulk import. For example, you can upgrade from previous versions of SharePoint by performing a database attach, importing the content as it was in the previous version’s environment. Alternatively, you can also migrate individual repositories, such as backing up and restoring individual SharePoint sites or site collections in the new environment.
The actual details of the migration itself depend on individual project circumstances, but I approach all my projects by following the five steps I mentioned. Sometimes a migration tool works best by automating most of the effort, other times the process requires more human involvement to decide what to keep and what to revise and what to purge. And sometimes the best approach is to recreate a lot of the content, such as when you want to refreshen the theme and subject of an intranet or online procedure manual.
Whatever your migration goals, these five steps guide you through the discovery, analysis, and design of your content migration plan.