Clients often tell me that they want to "upgrade their SharePoint" without understanding what it is that they are requesting. "Upgrade" makes the process sound much easier than it actually is.
When you upgrade Microsoft Office, you can open all of your old documents in the new version after a simple install. If your previous version of Office was really old, the software might prompt you upon opening each document to convert it to the latest version — a one-time task that runs automatically.
People tend to think that a SharePoint "upgrade" is as simple as installing the latest version of SharePoint on the server, and then the content and documents will automatically port over. This could not be further from the truth!
I never use the term "upgrade" when speaking with clients about moving to the next version of SharePoint. The more relevant term is "migration." In my opinion, it is generally best to perform a clean install onto a new server and then selectively migrate the content over. Or at the very least, clean up the data on an existing implementation before migrating it to the newer version. It may just be semantics, but changing that one word from upgrade to migration can give a whole new meaning to the task at hand, as well as adjust people's expectations accordingly.
Know What You're Getting Into
Before taking on any migration project, you should examine the current environment to understand what you are working with. Some of the questions you should ask include:
1. How big are the content databases?
While they can be much larger, Microsoft recommends that content databases not be larger than 200 GB, else you could run into performance issues. I would add — from first-hand experience — that it is extremely difficult to migrate a very large content database to a new server in a timely manner, especially if you are doing a double hop from SharePoint 2007 to 2013. This is something to keep in mind if your maintenance window isn't very large.
2. How are the sites structured?
Is there one giant site collection with many subsites? This may be an opportunity to restructure the subsites into their own site collections in order to keep the content databases at a manageable size. Separate site collections can reside in different content databases, however, you can't split a single site collection into multiple databases.
3. Are you utilizing information architecture best practices?
In other words, were your documents originally just ported into SharePoint from the file share? If so, this is a great time to establish your metadata strategy before migrating to a newer version of SharePoint.
Perform Clean Up
Migrating to a new version of SharePoint is the perfect opportunity to clean up your content. I have yet to come across a company that implemented SharePoint perfectly the first time around. There could be a variety of reasons for this, including not following best practices when originally setting up SharePoint, hiring someone who didn't know what he was doing, or lack of governance which can lead to "site sprawl" and other issues.
It could also be a case of not really knowing what you want the first time around. It's been said that it isn't until the second or third time you build a house that you are completely satisfied with it. This could be because you don't think of all the little details that you want at first. But you learn along the way and request those features in your next house, if you build again.
Similarly, once you start working with SharePoint, you will discover all the things that you can do with it that you never thought about before. You'll want to be sure to implement those features the correct way the next time around, with proper planning, instead of as an afterthought.
The bottom line is, if you move your current mess, you'll still have a mess. Except this mess will have a completely different interface, which will make it that much more frustrating for users. So take the time to clean up your content prior to migrating.
Take Baby Steps
If you do have a very large SharePoint implementation and it is not feasible to migrate it all at once, you can take smaller steps and migrate content a little bit at a time. Take the time to prioritize and plan out your strategy. Which sites you move first will depend on several criteria. For example, you may have departments that have pressing business needs and want to take advantage of new features in the latest version. Moving smaller sites first may be a good test of the process to increase your comfort level before tackling a larger or more high profile site.
The downside of this iterative approach is that users may need to be familiar with two different interfaces for a while, but this is temporary until all the content gets migrated over. You may want to take steps to integrate the navigation across platforms as well, so that users can still easily find their content (assuming you aren't also completely changing the navigation structure).
Ditch the Upgrade
There’s much more to “upgrading” SharePoint than simply installing some software on the server. The next time you hear someone say that they want to upgrade SharePoint, make sure they understand everything that is involved, and that it is much more than a simple upgrade. Migration is a much better term to use.
About the Author
Wendy Neal is senior SharePoint consultant for McGladrey and a founding partner and community representative for SharePoint-Community.net. A regular speaker at industry and user group events, she also maintains a popular SharePoint blog at sharepointwendy.com and discusses all things SharePoint (and sometimes bacon) on Twitter at @SharePointWendy.
- Gartner MQ for ECM: Why the Leaders Stand Out
- The Metamorphosis of the Social Enterprise
- SWAM: When LinkedIn Locks Down Social Networking
- Why Agile As We Know It Will Disappear
- Just How Badly Does Microsoft Want Your OneDrive Biz?
- ROI Is the Wrong Tool to Justify Social Investments
- Oops! Is Rackspace Rethinking its 99.99% Uptime Boast?