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.