I've seen a persistent trend in SharePoint upgrade project plans that seems to virtually guarantee your upgrade project will fail miserably in one way or another.
The flavors and timing of the failure can be diverse, but the impact on time and total cost to the company remains consistently severe.
Question: When is an Upgrade just an Upgrade?
Answer: Never.
Picture this scenario:
You have a functioning 2003 or 2007 implementation showing its age, and you want to get with the times and go 2010. You have deployed one or more 3rd party web parts over the years, kept some, thrown out others, implemented some custom branding here and there, maybe a 2007 theme, perhaps a site definition or two. You have content areas that are heavily used, some that aren't. You are too busy to know who is using what in the site, which content is fresh, stale, in progress, abandoned, or out of compliance with your industry regulations.
One day you are told, or decide, you must upgrade to 2010. The team assembles, or you call your vendor, and order One Tall Upgrade, Triple Latte, To Go. Now. Money's tight, everyone's busy, so you Just Want The Upgrade. Nothing else, thank you. Just Upgrade.
The project plan gets approved, budget's in the bag, and the work begins. Everyone feels clever because you have done due diligence and included a Disaster and Recovery plan, padded for downtime, applied all those lessons learned from years of experience with other system upgrades. There is no way the project can fail.
Then the pain begins. Perhaps slowly, perhaps quickly, but it comes. And in many flavors. Common symptoms that the pain is on its way are questions and observations such as:
"upgrade check is telling me we're missing some webparts... anyone know where they are?"
"hey, are we still using those custom web parts we deployed 2 years ago?"
"there's a kajillion petaflops of company party photos in here, do we still need those, cause the db is way too big"
"oh, the 2007 theme we're using cant be upgraded, sorry. I think we might lose our branding..."
"can I delete the billions of deleted items in the recycle bin, or should I keep those?"
"Is anyone still using X, Y and Z sites?" etc..
So it slowly dawns upon the team that for the Upgrade to be successfull, inventories are needed to identify:
- what lives where
- dependencies on custom solutions
- used vs. unused content and customizations
- places and features relying on branding
- Records vs. non-Records content for compliance etc
These reports can be quickly and easily generated. They can be made to look real shiny and purdy. A quick win on the brink of disaster shines and refracts like a beam of sunlight at dawn though the water cooler. Optimism quickly rebounds, sleeves are rolled up, nice inventories and reports are generated, tossed on a desk and then.... while everyone is still congratulating each other on cranking out the inventory reports so quickly, smiles begin to fade as the team suddenly realized that the spiffy reports by themselves are.... useless. The
Upgrade is still stalled for all the pivot charts and compiled inventories.
In the nervous silence, someone coughs and says "so... now we know what we've got, but, ah... who is going to decide what to do with this info? What do we keep, what do we toss?" If you are planning for failure, you will quickly scour at this individual and brand them with the scarlet plaque of raising unecessary Fear Uncertainty and Doubt, and shut them up. The underside of the carpet begins to look like the best repository for the freshly minted reports, and the budget, timeline and plan in need of serious "historical revisions".
Therin lies the fatal flaw that can guarantee a failed Upgrade, and the answer to why an Upgrade is never just an Upgrade.
Successfull Upgrade planning requires a measure of the same planning and execution a Content Migration or Keep/Toss process entails. And it is the most overlooked aspect in SharePoint upgrade planning in most project plans. Without it, however, an Upgrade is almost guaranteed to fail miserably.
I believe the root cause for the consistent failure behind incorporating and planning for Content Migration & Keep Toss steps as part of an Upgrade plan involves normal human avoidance of the same kinds of energy and effort required when moving between homes and deciding what to keep or throw away. The process of deciding what to keep toss, whether it is content, web parts, branding, etc, takes the same amount of emotional energy as getting a family together to decide what to keep and toss in a move. We all understand why all our own stuff should be kept moved in perfect condition, but can't understand why on earth someone else needs to keep all that junk. I think I get to say whether or not we keep that old painting, but someone else in the family might feel equally entitled.
It's a messy human process, so avoidance is natural. But it is a critical one for a successfull SharePoint Upgrade, where the cost can range from complete failure to upgrade anything at all to garbage-in-garbage-out scenarios, where your old Nova looks like a Hummer, but still drives like a Nova.
If you want to guarantee a failed, or at least very painful SharePoint Upgrade, ignore any and all need to plan for and schedule Content Migration/Keep Toss meetings within your organization.
If you'd like to ensure a fundamental baseline of success in your Upgrade, include Content Migration and Keep/Toss planning as a vital part of your Upgrade planning. Invest up front, be prepared for some hard keep/toss decisions, from content to web part, subwebs to branding, and embrace that reality.
When is a successfull Upgrade just an Upgrade?
Never. It is always an Upgrade and Content Migration/KeepToss effort.