Upgrading to SharePoint 2013: The Planning Starts Now

SharePoint 2010 is version 4 of the product, but is labeled “version 14” to align with Microsoft Office versions. While the rest of us are battling to align SharePoint 2010 with our current business requirements, Microsoft is busy planning SharePoint version 15. While there is nothing near to a release date yet, let’s step out on a limb and call it SharePoint 2013 (software branding isn’t that creative, is it?). In fact I’ve heard a Microsoft employee refer to “vNext” meaning version 16… The product group lives in a different plane of space and time.

 
SharePoint Server Farm

Upgrading SharePoint Doesn't Have To Be Painful

At the SharePoint Summit in Toronto last month, an attendee stood up at the end of the keynote and asked, “Upgrading to SharePoint 2010 has been so painful… What can I do to reduce the pain of upgrading to the next version of SharePoint?”

His statement—that upgrading has been painful—is something I hear all the time. It’s true, upgrading can be painful, though it does not have to be painful. His question really nailed it, though:  It’s not the upgrade to a new version of SharePoint that makes our lives painful, it’s everything we do between upgrades that makes an upgrade painful.  So now that you’ve upgraded to SharePoint 2010—or are planning an upgrade to SharePoint 2010, what can you do to make the next upgrade easier? The answer, in my opinion, lies in careful planning and design of your farms, web applications, and site collections.

Consider a vanilla SharePoint 2007 farm, with web applications and site collections that use only out-of-box features of SharePoint. How difficult is it to upgrade that farm? Not at all… you run the Preupgrade Check, then do an “in place upgrade” and voilà you have a SharePoint 2010 farm.

But that’s a fantasy, isn’t it? 

Custom Solutions, Code, and Tools Make Upgrade Challenging

Who among us has a vanilla SharePoint 2007 farm with only out-of-box features? Most of us have added custom solutions, custom code, and tools that sit on top of SharePoint 2007. Those are the bits that make upgrade challenging. We have to validate each component for compatibility with SharePoint 2010. We discover some components—like some of the “Fabulous 40 Templates” that Microsoft itself produced in SharePoint 2007 days—cannot be upgraded. We learn that some of our third-party vendors don’t yet have a SharePoint 2010 compatible release, or that the cost of upgrading those tools is too high. We find that some of our custom code was written by developers or consultants who are no longer available to help us remediate compatibility problems.

These are the painful parts of upgrade. Evaluating and validating all the “extras” and customizations is a time consuming and sometimes futile task. Meanwhile our customers are clamoring for the incredible new features of SharePoint 2010—whether that’s Office Web Apps, FAST Search and PerformancePoint, managed metadata, in-place records management, or any number of myriad improvements. And our administrators want to take advantage of improvements in SharePoint 2010’s infrastructure and management story. We can’t get there fast enough, but we’re stuck in a quagmire of compatibility.

Folks, this is going to be the story, moving forward. Thought the upgrade from XP to Vista/Win7 was tough? Now, instead of one user’s computer being a problem because of an incompatible application that is mission critical to that user—which prevented us from upgrading that user’s system while we moved on to other users’ systems—we now have components that are mission critical integrated into a server-based platform that blocks upgrade of an entire farm.

What’s the Solution?

Honestly, I don’t have a “silver bullet” answer, but rather I have a proposal that I hope will generate discussion and experience-sharing. The proposal is to stop throwing every component that a team requires into a single site collection, web application, or even farm. Instead, consider aiming for a logical architecture—a “containment hierarchy” of farms, web applications, and site collections—that give you a clear delineation between “vanilla” and “customized” SharePoint. Consider giving each team a site collection to support their collaboration—using the 80/20 rule—using only out-of-box functionality. If they need functionality that requires a custom component, put that functionality into a separate site collection. Add a navigation link from the vanilla team site to the customized site collection so that users perceive it as a single “solution”, but behind the scenes you’ve actually got a containment hierarchy that keeps vanilla and customized elements separate.

Consider, then, the upgrade story to SharePoint 2013. You can upgrade the vanilla site collection quickly, giving immediate access to the improvements Microsoft will make to the platform, but the specific functionality that required a custom solution can remain on a SharePoint 2010 farm, with a link from the upgraded site collection back to the customized site collection.  Think about it—if the functionality was that “custom”, it probably won’t need upgrading—it does its job and meets requirements already. Or, Microsoft will introduce a new feature in SharePoint 2013 that replaces the need for the customized “container”, and you can just retire the custom solution and use the new out-of-box functionality.

Structure SharePoint To Align with Business Requirements

Take this to the level of web applications and farms. Let’s jump up to the farm level. If you’re going to install a farm solution, do you want that in your “primary” farm as a potential block to upgrade? Or are you better off hosting that custom solution in a separate farm?

Those of you who have seen me present “live”, or who will join us at SharePoint Connections or in one of the cities we’re visiting on the SharePoint Coast-to-Coast tour will know I go into great detail about how to structure a SharePoint service—the farms, web applications, site collections, and sites—to align with your business requirements. The better you do that, the better your upgrade experience will be. If you have everything in a single farm, in a handful of Web applications, and in a limited number of site collections, you’re going to find that there are incompatibilities that must be remedied and dependencies between compatible and incompatible components that make life miserable. If your containment hierarchy is modeled in alignment with your business requirements, you’ll find that you can upgrade the parts of your service that will benefit from new features—easily—and continue to get the functionality that you built to meet specific requirements from your “old” farm. 

It’s a tough concept to boil down into a column, but hopefully you can consider that fantasy of a completely vanilla farm and how easy it is to upgrade, and then look carefully at where you are intentionally and for good reason deviating from a vanilla implementation, with full awareness that the decisions you make about how to meet your business requirements with customizations now will absolutely impact your upgrade to SharePoint 2013.  Because I’m sure that, as with SharePoint 2010, Microsoft will make the upgrade to SharePoint 2013 from its own SharePoint 2010 “bits” pretty easy and straightforward… It’s only our choices about how to make SharePoint 2010 align with our business requirements that can make it more painful.