As most of the SharePoint world may have heard by now; SharePoint 2016 is available as of May 4th, 2016 for purchase commercially; via MSDN; and through software assurance and volume licensing agreements you may have established with Microsoft. As tends to be the cycle over the past decade, this means many of us will be scrambling to understand what SharePoint 2016 offers; and to begin the upgrade "pitch" to your stakeholders to upgrade from your current version of SharePoint to the latest/greatest iteration of the platform.
SharePoint 2016 is the time to break that cycle. The era of the "every 3-year big upgrade" (or every 6- year upgrade for those of you still running SharePoint 2010) is over.
SharePoint 2016 brings some great features to the table (which we'll document in subsequent posts over the next few months); however, to just upgrade from our existing assets "as-is" to SharePoint 2016 is really selling the platform short.
First – Take a Step Back
Before you begin planning for SharePoint 2016 farm sizes and configurations (and admittedly, the MinRole farm configuration is great for larger organizations), you need to take a step back and determine what business goals SharePoint is currently meeting (or failing to meet).
Chances are you have a SharePoint "Governance Plan" that was created years ago, and it probably started off with a paragraph stating the "Platform Vision Statement" for SharePoint. A lot has changed in the SharePoint world between SharePoint 2010 and today. Namely, SharePoint has lost some features (or no investment has been made in them, causing them to be passed up by complementary products).
Below are the main components that SharePoint 2016 On-Premises no longer offers (or sustains no major changes within):
- Foundation – SharePoint Foundation has ended at 2013. There is no more free ride in the SharePoint world. That being said, SharePoint Standard and Enterprise now no longer require "For Internet Sites" licenses, which can many times replace Foundation features and functionality for external users.
- Business Connectivity Services – Limited investment has been made into BCS in the past two iterations of SharePoint. BCS is still very much an option within SharePoint 2016; but more often than not, organizations can achieve a better integration between LOB systems and SharePoint with more modern development techniques utilizing client-side development, REST and ODATA services, and OAuth.
- Public Web Site Authoring – SharePoint 2013 brought some nice-to-have improvements to the public WCM stack; but SharePoint has been lapped by other products (Sitefinity, SiteCore, and even Wordpress) for most organizations, where if you're still hosting your public web site on SharePoint; it probably makes sense to start eyeing a new platform rather than maintaining the environment through another SharePoint upgrade.
- Meeting and Workspaces – This has been discussed many times; but SharePoint 2013 allowed for the bypassing of this deprecated feature, this feature is now gone from SharePoint 2016.
- InfoPath Form Services – While IPFS is still included in SharePoint 2016; the designer and filler have stopped at 2013. While IPFS is supported (and will continue to be supported for the duration of SharePoint 2016's life cycle), now may be the time to stop investing further in InfoPath and begin focusing on more modern solutions such as Nintex or the new PowerApps platform in Office 365.
Take a few hours to interview existing SharePoint stakeholders, and find out what's currently working for them; and what pain points they are experiencing. SharePoint may not be the solution to all of their pain points, but there's no time like planning an upgrade to determine how those issues may be addressed.
Outcomes of these findings could be categorized in the following manner:
Now that we have a solid inventory of what is in our current SharePoint environment, we should now begin to build out a plan for what should go where.
Next - Make a Plan
If you have Office 365 at your disposal, it's time now to determine what role you want to support for SharePoint Online. If you want to move some portion of your on-premises assets to Online (OneDrive for Business tends to be the workload that goes first), but you have some components that must remain on premises such as some advanced BI workloads, or sites with third-party products that aren't cloud-friendly; you'll want to take a look at configuring your SharePoint 2016 farm for a hybrid configuration.
From a high-level, the main decision points for your migration are below, for each type of asset:
- It's Perfect As-Is - This is the easy one. Decide if it should remain on-premises, or be migrated as-is to SharePoint Online. If the latter; should you migrate it with a third party tool (such as Sharegate) or via the SharePoint Online Migration API. If you are doing more than a few sites; Shargate will pay for itself very quickly.
- It's Old and Unused - Is it worth upgrading your old IT site that hasn't been touched in 5 years? Maybe we pull down the documents and libraries inside of here, move them off to an archive site, or even better, just leave the site behind and don't worry about migrating it anymore.
- It's Grown Too Big - If your SharePoint sites have grown too big (either too many items in a single list or library, or too many sites underneath a site), a migration is a perfect time to reorganize your content.
- It's Working, but Not Well - Candidly, many times, during a migration; you're going to have enough on your plate. Unless there's an easy fix for items; it might be best to capture these issues and resolve them at a later date when there are fewer moving pieces to coordinate.
Once you have all of your assets mapped out; the fun part comes, building the SharePoint 2016 environment, configuring your SharePoint Online tenant, and beginning your migration. We'll go more in-depth on this in later posts.
Is your environment setup for maximum efficiency?
Request a FREE SharePoint Environment Review Session!
Posted by Justin Kobel
Justin Kobel is the Practice Lead over the SharePoint practice at KiZAN Technologies and has been with KiZAN since 2005. Justin has experience as a developer, engineer and architect on all technologies surrounding SharePoint.