With the release of SharePoint 2010, Microsoft continues to grow its already compelling content management platform. And although many enterprises are thinking about a move to SharePoint 2010, they aren’t necessarily coming from the same place.
The difference between migration and upgrade
Often the terms migration and upgrade are used synonymously. But each term actually describes a mutually distinctive path. By definition, an upgrade is the act of loading the new version of SharePoint on your existing farm. This process involves -- at the least -- changing the underlying binary files, altering all of the content databases associated with your SharePoint environment and potentially changing aspects of your SharePoint sites. Unfortunately, this approach is available only to a narrow set of SharePoint implementations that are already SharePoint 2007. Companies that don’t have the upgrade option must migrate content to a new SharePoint farm.
For instance, a number of firms are still using SharePoint 2003, and some are even contemplating the choice of moving to the cloud and using SharePoint Online. And then there are those that haven’t implemented SharePoint at all.
In any of these scenarios, the typical “upgrade” from one version to the next in the sequence isn’t an option. So instead, some firms need to look at other alternatives to move their content into the latest SharePoint version.
First, it’s important to understand that migration isn’t a second-tier choice. Migration is simply another choice available to move your content into a SharePoint 2010 environment -- even if you have an upgrade option available to you. And, like upgrading, there are a set of decisions you’ll need to make to ensure success. Please keep in mind, though, that everyone’s SharePoint environment will be somewhat unique. These best practices are a good start, but you should do your own independent research.
Plan and document
It may seem obvious, but planning and documenting your migration is a critical step. Your efforts should be focused first on creating a paper version of your SharePoint 2010 environment. This process should include:
- Site Collections -- What site collections you’re going to create and what sites will be contained in those sites are important to document in advance.
- Site Types -- There are lots of new SharePoint Site Definitions available, as well as ones that resemble previous versions. Decide what you’re going to use.
- Metadata -- SharePoint 2010 deeply integrates metadata in virtually everything in the new platform. Even if you’re already using Content Types and columns in SharePoint 2007, you should take extra care to understand what’s available in 2010 and map out your usage.
- Workflow -- Know which workflows are associated with Content Types and which may be independent.
These four items are critical for content migration. But there are also a number of technical changes to the new platform that deserve to be planned out. These include service applications, as well as user/sandbox solutions. The focus here is content, but infrastructure planning is also important.
After you’ve created your environment on paper, map the source environment to the new one. This will involve “translating” between what you have now and what you will have in the new environment.
If you aren’t using SharePoint at all, you’ll need to decide how to move content from file shares into Sites and Libraries. If you have a SharePoint 2003 environment, how do your SharePoint areas translate to sites? If you have a SharePoint 2007 environment, decide whether common columns in different sites or libraries should become managed metadata and whether you’ll need a content type hub. You have to create “solutions” to these questions and document all the answers.
Choose a migration tool
Migrating even a small implementation or file share in SharePoint is not easy, so you shouldn’t try to migrate your content manually. But don’t worry -- a number of good products on the market now make migrating to SharePoint 2010 relatively painless. Here’s a list of just a few of them in no particular order:
- Metalogix SharePoint Site Migration Manager 2010 -- Metalogix Software Corp. has been in the migration space probably the longest and started during the content management server days. Its migration product supports a variety of migration scenarios, though licensing differs among components.
- MetaVis Migrator -- Although it can be licensed separately, Migrator is really a part of a larger suite of products designed for SharePoint. The tool supports movement between SharePoint versions and file shares.
- Quest Software Migration Manager -- A relative newcomer in the SharePoint space, Quest has quickly grown its collection of SharePoint-related products through acquisition and organic creation. Its migration product can move content between SharePoint 2003, 2007 and 2010 farms.
The tools mentioned here aren’t exhaustive, and they don’t include open source utilities like SharePoint migration projects on CodePlex. Investigate license costs, and determine the fit for your situation. There is a fair bit of variation in both cost and fitness, depending on what you’re migrating and how much -- data migration size is often a license cost variable.
Migrating content Is only part of the story
The effort of migrating to a new SharePoint farm is more complicated than just content. If you ran a SharePoint 2007 farm, you may have the customizations you need, like master pages or page layouts. If you’re migrating a publishing site -- especially for an external website -- now you need to move to the new farm.
Test your migration
Before you go live, test your migration. Although you may have planned well, you won’t be able to accurately predict the outcome of your migration until you’ve tested it.
Most individuals tasked with migration will likely perform only a content audit and not a complete inventory to establish a content pattern that is, what you have, how much of each type and how to describe it. Because of that, there will be content that “breaks” the constructs you’ve created. Your test migration will highlight those anomalies and enable you to fine-tune the migration.
Beyond just testing the tool and your plan, you’ll want others to review your work. This means getting your end users to test-drive a sample migration site. During your planning stage, you probably make assumptions about site types and organization. These assumptions may prove slightly or even severely wrong. Correct those errors before committing to a final migration process.
Much like your testing process, you’ll want to touch base with the original testers and expand the group to include new faces. The post-migration testing will highlight any remaining issues with your migration process.
Unlike the first testing process you went through, correcting flaws at this stage will likely be manual. For example, the name of a library might be wrong or a site might be in the wrong section of the hierarchy. These issues are relatively minor and easy to correct. If, however, you’ve missed metadata on a major content type, it may require a bit more work. Adding a column to a content type is easy, but assigning the right value across 10,000 files may be more challenging.
There will still be issues, but if you’ve followed these steps, those issues should be minor and correctable. Once you’ve completed your post-migration testing, you can release your new site to your user community.
ABOUT THE AUTHOR:
Shawn Shell is the founder and principal consultant at Consejo Inc., a firm specializing in the development of information worker solutions. Shell has spent more than 20 years in IT, with a focus on the development of portal, collaboration and content management solutions. He is an expert on SharePoint, Office, Microsoft Content Management Server and custom ASP.NET applications, as well as a contributing analyst for the Real Story Group and a co-author of Microsoft Content Management Server 2002: A Complete Guide, published by Addison-Wesley. Check out his blog at http://blog.consejoinc.com, and follow him on Twitter @shawnshell.