SharePoint Online Implementation Roadmap

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.

NOTE: I may have opened this post with a cynical view of consultants delivering implementation roadmaps. That said, I feel strongly that the best path to success in the cloud is to take that journey with a good services partner. A good partner can make all the difference in the world in an Office 365 implementation.


SharePoint as a Service

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.

Pope Benedict XVI Inauguration (2005) Pope Francis Inauguration (2013)


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:

  • Notice the innovation gap that occurs between a major release and when a customer actually upgrades. I still have customers on SharePoint 2003, so this gap can be much more substantial than the chart represents
  • Notice how SharePoint Online recently surpassed SharePoint Server in innovation and is on a trajectory to stay ahead. When SharePoint 2013 was first released, there were a number of features unavailable to the cloud (ex: content by search, cross-site publishing, etc). Although feature disparities still exist, more gaps exist on-premises with a flood of recent cloud-only features such as Power BI, Video Portals, Delve, Storage Capacities, etc
  • SharePoint Online innovation does not plateau…it offers continuous innovation to customers that have adopted the service
Chart Showing SharePoint Innovation Trends over Time

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

Implementation Preparation

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.

Implementation Approaches

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.

Commodity Approach

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.

Specialty Approach

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:

  • Already have an intranet redesign in this years budget?
  • Looking to deliver a special workload like a corporate YouTube or Knowledge Center in SharePoint?
  • Have a one-off process that you want to deliver and manage in SharePoint (ex: Procurement)?
  • Want a jump start in delivering enterprise social features to your organization?
  • Intrigued by some of the new cloud-only features like Delve, Office 365 Groups, Power BI, or the new Video Portals?

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.

“Fictitious” Hybrid Search with Single Result/Relevancy

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.

Hybrid Search via Common Search Experience/Navigation

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.

Hybrid Search via Remote Search Federation

Enterprise Social

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.

Configuring Social Platform for SharePoint Online

I recommend Office 365 customers use Yammer as their enterprise social platform for the following reasons:

  • Yammer offers a more mature and feature-rich social platform with native polls, praises, groups, graph APIs, better mobile clients, and much more
  • Deploying Yammer has no impact on the SharePoint Online footprint compared to SharePoint Social which requires OneDrive for Business sites (read: Yammer gives you more time to get your Information Architecture plan in order)
  • Microsoft will be focusing the majority of social investments in the Yammer platform…not SharePoint Social
  • The Yammer/SharePoint integration efforts have already made great progress, including document-contextual threads/post-to, search scopes, and Yammer apps/embeds
  • Where Yammer/SharePoint integration lacks, the Office 365 Developer Patterns and Practices offers provisioning samples for tighter integration (ex: provisioning Yammer groups or graph object with site provisioning). This also aligns with the Information Architecture recommendation of owning the site provisioning process
  • Yammer offers numerous resources for customer success including hands-on experts, case studies, and customer networks
  • Office 365 Enterprise, Mid-Sized Business and Education customers likely already own Yammer Enterprise

Final Thoughts

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.

Comments (7)

  1. Spencer Harbar says:

    good article, however a release does not equal innovation and to paint them as such is a misrepresentation of SharePoint in the enterprise. it's also an inaccurate depiction of the reality of both on premises and cloud offerings from Microsoft in this space. When working with the enterprise on roadmaps, or even simply some basic strategic planning, it's generally not a great idea to start with such misrepresentations, even though the overall headline is accurate.

  2. Hey Spence…I appreciate the perspective. I'll completely agree with you that new releases/features does not equal "innovative". Apple could add NFC to the next iPhone and that wouldn't be "innovative", but it would be an "innovation" for the iPhone. For that reason, I do think new releases/features brings innovation to SharePoint. Just my $.02…not saying it is right. Thanks!

  3. Kelvin Kirby says:

    Hi Richard, This is a great blog article and thanks for posting. On minor point though – the assertion that the iPad did not exist when SharePoint 2010 was released is not strictly correct.

    The iPad device was announced and unveiled on January 27, 2010 at a media conference in the USA. On April 3, 2010, the Wi-Fi variant of the device was released in the United States, followed by the release of the Wi-Fi + Cellular variant on April 30. On May 28, it was released in Australia, Canada, France, Japan, Italy, Germany, Spain, Switzerland and the United Kingdom.

    SharePoint 2010 was released (as was Office 2010) on May 12, 2010.

    But the timing is very, very close, and its a totally reasonable assumption that SharePoint 2010 couldn't possibly have been developed or modified in time to support the iPad, which I guess is really the point of course. 🙂

    I think the big debate right now is how far will Microsoft go in terms of encroaching on partner services and livelihood. I know its a big debate within the members of IAMCP ( and a huge concern. 🙁

    Thanks again for posting



  4. Thanks for the note and clarifications Kelvin. "Unveiled" would probably have been a better choice of words in the post.  I say that because the iPad was complete speculation when SharePoint 2010 was unveiled at SPC 2009 in Vegas. After unveiling, we typically don't change much (mainly bug-fix).

    In terms of encroaching on partner services and livelihood…I think it depends on the partner space, but in most cases there are still huge opportunities. Office 365 customers are coming from a world with they needed HUGE capital budgets for upgrades and on-going maintenance/management of infrastructure. Most of that spend can be re-invested with partners…buying ISV tools and SI services to migrate and make the cloud work for better for their business. I know several partners thriving with SharePoint Online engagement for migrating content and customizations to the cloud. Hosting partners probably have the biggest threat, but there are still workloads we don't support in Office 365 (public sites, Lync voice, etc).

  5. TomResing says:


    I appreciate you taking the time to write out your thoughts on the subject. I identify with some of the comments Kelvin and Spence have already voiced and it's clear you've touched on subjects that many of us are wondering about.

    I love your illustration of the ideal search experience customers desire.

    Can you elaborate on why it's not possible to index on-premises from cloud or vice versa and how you see customers getting to their desired state? I know their are many ISV tool vendors like you mention and if you see them closing the gap.



  6. Hey Tom…thanks for the comment! The search indexing challenge is different depending on the direction you are indexing:

    Indexing SharePoint Server from SharePoint Online – Microsoft doesn't current expose content sources (not to be confused with results sources which provide federation) to Search Administration in the SharePoint admin center. As you know, index size planning is a BIG deal in the current platform and I think it is just too hard to predict what a customer might try indexing into the cloud. For example, what if a customer had a relatively small SharePoint Online footprint but wanted to index a HUGE on-premises farm (basically use SPO for a search farm). As it stands now, Microsoft can allow for linear growth between content databases and search indexes.

    Indexing SharePoint Online from SharePoint Server – I'm told BA Insight actually has a connector to accomplish this. However, I'm a little skeptical in promoting it as I'm curious at it's ability to throttle at large scale. As you know, crawling can really pound WFEs…crawling the cloud using normal CSOM/REST APIs (which is the only thing I could imagine them using) could appear as a denial of service attack. I think in the near-term…this scenario is more feasible than indexing in the SPO and worth a look.

    I would expect the "ideal" scenario to be possible at some point in the future and I would expect Azure to play a key role. Another challenge in realizing the "ideal" scenario goes beyond just indexing…we need common refinement. Keeping crawled and managed properties common in a hybrid landscape isn't easy (ex: "Business Unit" might mean different things and have different taxonomies in each place). Love where search has gone in SharePoint and excited to see how we solve some of these challenges.

    Thanks again for the comment…hope this response was helpful.


  7. Darrell Trimble says:

    Here's my blog on choosing the right consultant to match your needs.…/smbs-choosing-the-right-sharepoint-consultants-to-match-your-needs