This post will likely piss off a few consultant friends/readers that make a living selling “SharePoint Implementation Roadmaps”. These multi-week (sometimes multi-month) roadmap efforts produce hefty services fees and fluff documentation of obvious milestones (that will ultimately draw more consulting services to successfully deliver). The roadmap noise has gotten even louder with the insurgence of Office 365. Most enterprise customers own at least some Office 365 and are looking to maximize that investment. Of the services in Office 365, Exchange and Lync migrations tend to be more black/white compared to SharePoint’s 50 shades of gray. A week doesn’t go by where a customer doesn’t ask me “where do I start with SharePoint Online”. I’m going to simplify the answer into two generic approaches…either start with commodity sites or start with a specialty site. In this post, I’ll explain my logic behind these two generic approaches and some general implementation guidance for a successful migration to the cloud.
Before jumping into implementation approaches, it is very important to understand what it means to move SharePoint workloads to Office 365/SharePoint Online. Microsoft has traditionally released Office software in large waves. 2003, 2007, 2010, and 2013 have all been significant release years for Office/SharePoint. New releases bring new features and an elevated level of innovation in the products. Unfortunately, innovation would typically stay stagnant following a major release...at least until the next major release (~3 years later). A three year hold on innovation was more palatable a decade ago. Today, consumerization has enterprise users demanding the same levels of innovation they use at home. For Microsoft, moving from a three-year innovation cycle to continuous innovation was imperative for delivering the best productivity tools in the world.
Don’t believe me…consider the fact that the iPad didn’t exist when SharePoint 2010 was unveiled. By the release of SharePoint 2013 almost every enterprise user carried at least one touch device that SharePoint 2010 struggled to support. One of the most dramatic visualizations of this trend are the pictures below. Taken in 2005 and 2013 at the inaugurations of Popes Benedict and Francis (respectively), they illustrate the rapid rate of innovation our world is experiencing and demanding from Microsoft.
Rapid enterprise innovation would be great in an ideal world. In reality, most Microsoft customers struggle to keep up with the traditional 3-year release cycles. Upgrade blockers, budget/resource constraints, and conservative upgrade methodology keep most organizations at least a year or two behind current bits. To overcome this, Microsoft made the strategic decision to innovate cloud-first and in a much more frequent cadence (from every 3-years to every 3-months). This is a critical principle to understand of Office 365/SharePoint Online. You will stay innovative in SharePoint Online because we own the upgrade process and won't let you fall behind. The chart below illustrates innovation over time for SharePoint Server, SharePoint Online, and the typical on-premises SharePoint customer. A few important notes in the chart:
Continuous innovation can cause concerns for organizations mindful of the change management implications that come with rapid change. Microsoft tries to address these concerns through timely and thorough communications on the Office Blogs, MSDN, the Office 365 IT Pro network of Yammer, the Office 365 Message Center, and the Office 365 Change Management Guide for the Enterprise. Additionally, it is important to consider the magnitude of change. Innovation in the service will be steady, but likely more subtle than the traditional three-year upgrades
Before jumping into a SharePoint Online implementation, there are a number of steps that are recommended for better success and the user experience in the cloud. The first step is to ensure identity/authentication is configured correctly. Behind the scenes, SharePoint Online always uses identities from Azure Active Directory. These cloud identities originate in one of three ways...100% cloud identities, synchronized identities, or synchronized identities with federation. The diagram below summarizes these three options, but you can also reference Choosing a sign-in model for Office 365.
Cloud identities are users/groups that are provisioned directly into Azure AD using the Azure management portal or the Office 365 admin portal. This identity model is completely cloud-contained, meaning it doesn't require on-premises infrastructure and Office 365 will own the entire sign-in experience (including user passwords). The cloud identity approach is commonly used by small organizations, pilots, and POCs.
Synchronized identities are users/groups synchronized to Azure AD from an on-premises identity provider such as Active Directory. In addition to profile information, synchronized identities have their password hashes synchronized to Azure AD so they don't require separate passwords in the cloud. This option is simple and requires less infrastructure, but can be confusing in short periods following a password change (where passwords are temporarily out of sync). With synchronized identities, Office 365 will owns the entire sign-in experience (except for the passwords).
Federated identities are similar to synchronized identities in that users/groups are synchronized into Azure AD from an on-premises identity provider. However, password hashes are not synchronized in a federated identity model. Instead, Office 365 relies upon a federated service (typically ADFS) to own the login process. Office 365 trusts the federated identity provider to return a set of claims that Office 365 can use to "impersonate" the synchronized user accounts in Azure AD. The important aspect of federated identities is that the Office 365 customer owns the sign-in process...not Office 365.
SharePoint is a container-based technology (site collections, subsites, lists, libraries, etc) that isn’t easy to reorganize. As such, I highly recommend getting a better understanding of the different containers in SharePoint and their capacity constraints in SharePoint Online. Establishing a solid information architecture strategy is imperative since a wrong decision on information architecture can cost significant time and money to fix (ex: converting a subsite into a site collection requires a migration tool). I recently authored a post on SharePoint Online Information Architecture Considerations that explains some of the primary constraints and patterns for IA in the cloud, including URL limitations, capacity constraints, templates/provisioning, and managed metadata/content types.
I’ve seen numerous methods for implementing SharePoint Online, but most successful implementations can be summarized into two approaches…the “Commodity Approach” and the “Specialty Approach”. I have never seen a successful “big bang” implementation, so both of my recommendations follow an agile methodology for delivering quick wins over time. With an agile migration to the cloud, most customers will be left (at least temporarily) in a hybrid state. “Hybrid” exists when some SharePoint content exists on-premises and some exists in the cloud. This has special considerations that I’ll cover after detailing “Commodity" and "Specialty" approaches.
The idea behind the Commodity Approach to SharePoint Online implementations is to start with “commodity” sites. Commodity sites are sites with little differentiation that are provisioned to satisfy a want or need. Examples of commodity sites include OneDrive for Business sites (aka – personal sites) and Team/Project sites. These workloads demand very little differentiation, so they fit nicely into a commodity or “cookie-cutter” model. They typically require very little customization and can immediately benefit from being cloud-hosted (internet accessible, easy external sharing, increased storage quotas, always current, etc). For these reasons, commodity sites are a very popular and successful place to start in SharePoint Online. In fact, Microsoft began their internal move to SharePoint Online with OneDrive for Business and new team sites. Commodity sites are typically great candidates for self-service provisioning/disposition strategies. For more information on this, see the Office 365 Development Patterns and Practices on GitHub.
Commodity sites typically have the largest footprint in a SharePoint deployment. This makes migration of existing on-premises commodity sites an important consideration in a SharePoint Online implementation strategy. For migrating commodity sites, I’ve seen two successful strategies...”let them move it” and “move it for them”. With “let them move it”, the benefits of SharePoint Online are socialized to the organization and users are encouraged to manually migrate their own content into the cloud. With “move it for them”, migration tools are used to migrate existing on-premises content for users. Microsoft took a hybrid approach to migrations that worked incredibly well. We started with a 6-month self-service migration period for OneDrive and Team/Project sites. After the 6-month self-service period, we offered migration services for remaining legacy sites and disposed of many other sites. We found that most users were motivated to migrate their content to a) clean up the mess in their existing on-premises sites and b) get access to the great new features exclusive to SharePoint Online (internet accessible, easy external sharing, increased storage quotas, always current, etc). At the end of the self-service migration period, we had significantly less content to migrate than expected (which is a good thing since most migration tools charge by content volume).
I want to be clear that Microsoft did not cut corners in our own migration to the cloud. Although we own the service, we didn’t perform our migration using back-door methods unavailable to our customers (ex: content database attach). We used the same migration tools available to you, such as Dell’s (formerly Quest) Migration Suite for SharePoint, AvePoint’s DocAve Migrator, Metalogix’s Content Matrix, and several others. Most of the migration tools achieve similar results, so I don’t endorse or recommend any specific one. I recommend you evaluate migration tools based on existing vendor relationships, migration requirements, and budget constraints.
Implementing SharePoint Online with a "Specialty Approach" makes sense when your organization has an immediate SharePoint need or initiative that would be a good candidate for the cloud. “Specialty” refers to a special one-off need and can take many forms:
If you said yes to any of these, you might be a candidate for a Specialty Approach to SharePoint Online implementations. Like commodity sites that have minimal customizations, specialty sites are also a low-risk place to start SharePoint Online given their small footprint (usually just a few site collections). A specialty approach can also help generate migration momentum for commodity sites. Although Microsoft started with a Commodity Approach for our own migration, we quickly shifted focus to specialty sites once OneDrive and Team sites were rolling in the cloud.
Unless your organization is brand new to SharePoint, your first delve into SharePoint Online will immediately put you in a “hybrid” SharePoint landscape. Hybrid is a term used to describe a SharePoint deployment where content exists both on-premises and in the cloud. A hybrid SharePoint deployment comes with special considerations, especially when it comes to content search/discoverability. SharePoint search builds an index of content so it can deliver quick search results (similar to how the index in the back of a book works). In a hybrid configuration, you will have content in at least two places, neither of which can index the other. This introduces a disjointed search user experience with no ideal solution. An ideal search solution would allow search results to be returned from anywhere in a single set of results and relevancy. Although you can deliver a good user experience in hybrid scenarios, you cannot pull hybrid content into a single index (and thus no single results/relevancy). The hybrid search options available in SharePoint Online include a common search navigation or hybrid search federation. I’ve provided illustrations to better understand the user experience of each option. Below is a fictitious example of what an ideal search solution would look like if we could deliver a single results/relevancy. Notice how results from SharePoint On-Premises and SharePoint Online and intermixed based on one relevancy in this fictitious mock-up.
Option 1 - Common Search Navigation: With common search navigation, you will deliver 2+ search centers with a common user experience. At least one of the search centers will be delivered in SharePoint Online for delivering search results from the cloud. Ultimately, on-premises search centers will return on-premises search results and online search centers will deliver cloud search results. Leveraging a common user experience is what ties everything together. More specifically, an identical search navigation (also referred to as “scopes”) can give search the perception of being one experience (even though the user might be jumping between SharePoint Server and SharePoint Online). This is an elegantly simple solution to the hybrid challenge and one that has been popular inside Microsoft. It doesn’t require any scripts or trusts, just management of a search user experience in 2+ places. You can see in the illustration below that the user experience of the search centers are identical as the user jumps between cloud and on-premises by clicking on different search navigation links. If not for the URL changing, the user wouldn’t know they are jumping between farms. You can also see that no efforts are made to include hybrid results on the same page...cloud pages show cloud results and on-premises pages show on-premises results.
Option 2 - Hybrid Search Federation: with hybrid search federation, you can deliver hybrid results on the same page (from SharePoint Server or SharePoint Online). However, the remote results will display in a separate display block. This configuration is often referred to as “remote indexing”, a term I find a little misleading since we aren’t actually indexing anything remote (just reading a remote index). Hybrid search federation does achieve at getting all results on one page. However, real remote indexing would allow search results to be returned with a single relevancy (read: no result blocks). The configuration to deliver hybrid search federation is outlined on MSDN and requires a multi-step configuration by an administrator on each end. Notice in the illustration that hybrid results are delivered on the same page, but in separate blocks and relevancy.
Enterprise Social is a specialty workload popular for introducing Office 365 to the enterprise. It can set the foundation for enriched experiences through SharePoint, as ALL sites can benefit from social features such as pictures, profile information, likes, and shares. Office 365 offers two enterprise social platforms with SharePoint Social and Yammer. The SharePoint admin center allows administrators so select between these two options.
I recommend Office 365 customers use Yammer as their enterprise social platform for the following reasons:
Although there are many pathways to SharePoint Online, most implementations start with commodity sites or a specialty site. Taking an agile bite out of the cloud can deliver a quick win that can set the momentum for successful cloud adoption. This post wasn’t meant to serve as a implementation roadmap replacement. My goal was to offer implementation patterns that have been successful with other customers so you can form your own implementation roadmap.