One of the major complaints about SharePoint is that, while it contains the potential for expanded business productivity and automation, within many organizations it has become yet another file share. 

While that may be true, the primary difference is that, unlike those old file shares, SharePoint has the potential to be expanded upon. It is the sleeping giant in the organization. And funny enough, one of the major trends these days is movement of old network file shares and their vast volumes of unstructured data into SharePoint.

Let's examine why this shift is happening. For one, the adoption lifecycle for SharePoint as a platform is maturing, with over 80 percent of the Fortune 500 companies either owning 2010 or planning to move to 2010. SharePoint adds many benefits that file shares just can’t provide, including retention policies, taxonomy and metadata, business productivity through workflow and forms, and robust document editing and versioning capability, to name a few.

The number one reason organizations delay their file share migration to SharePoint is fear of the unknown -- they simply don't know where to start.

Understanding the Options

According to my colleague Mark McGovern, the logical place to begin the planning process of moving network file shares to SharePoint is to do an inventory, and determine which types of file shares are appropriate to migrate and which are not:

Some questions to ask during this process are: What is the volume of content to be moved? How often is it accessed? Does it need to be retained for a set period due to compliance reasons? Are the documents highly collaborative? Lots of small documents that are modified frequently and need to be retained for a given period would be a great candidate for migration. It is usually a combination of factors that determines the decision."

The next place that many organizations get "stuck" is in deciding the method for the migration. Depending on the skillset on hand, the timeframe in which to move the content or the complexity of content (multiple versions, historical metadata or maybe just the sheer volume of content), administrators can attempt to do it manually, they can engage their developers to write some custom code or use PowerShell scripts, or they can purchase one of many 3rd party tools on the market that support the SharePoint environment.

As Mark points out, the answer to that question -- as with all difficult decisions in the SharePoint world -- is that "It depends."

Mark adds,

There are pros and cons of each method. For example, when uploading files manually, the CreatedBy, CreatedDate, ModifedBy and ModifiedDate are not maintained. For legal reasons, this loss of historical metadata may rule out this method. Fortunately, there are tools on the market that can retain this important metadata."

Migration Considerations

Most file shares have become a dumping ground for content. While there may be valuable content within your system, it is likely you also have massive amounts of duplicate, outdated and unnecessary content that should be purged from your system. As you prepare to move this content, some questions you should ask include:

Learning Opportunities

  • Do you know what content is out there?
  • Do you know who owns the content, and whether it even needs to be moved? (maybe it can remain, but indexed and therefore searchable)
  • Is the folder structure important?
  • Do you need to maintain historic metadata?
  • Is the plan to move the content as-is and decommission your hardware, or will you attempt to organize/clean up the content prior to your migration?
  • Will some content remain on the old system? (it might be tied to other internal tools that are not yet ready to move to SharePoint, or may never move to SharePoint)
  • Are you planning to apply metadata and taxonomy? (using the existing folder structure, or creating a new taxonomy)
  • Are users driving the clean up and tagging process, or is it an administrative effort?

Whatever method you decide to employ, the single most important aspect of migrating file share content to SharePoint is the metadata applied. As much as possible, make sure that you tag your documents with metadata during the migration, as applying metadata later can be labor-intensive, and you may introduce a greater potential for human error (you miss some of the content, don't apply new metadata or content types everywhere).Adding metadata tags during the migration makes your content more “findable” and easier to surface through search or through SharePoint's social capabilities.

The number one reason why end users become frustrated with SharePoint is their inability to find content. Metadata assignment is a key to success. As Mark points out, part of a successful migration process is to allow the end users to manage as much of the metadata assignment activities as possible, from taxonomy and content type development to the actual applying of metadata to content:

SharePoint administrators do not have the knowledge to tag individual files with metadata. The content authors, who know those files best, need to participate in the process.This participation ensures that the files are tagged correctly and increases the value of those files."

And the more findable content becomes, the more usable SharePoint becomes.

While there are many business decisions that need to be made around file share migrations to SharePoint, the primary decisions are what to move, how to move it and how to tag it. Answer these questions, and the only major issue you'll face is the not-so-small task of executing your plan. Good luck.

Title image courtesy of Michael D Brown (Shutterstock)

Editor's Note: Christian writes frequently about SharePoint, so you may be interested in reading more of his articles