needs to make the transition. As the cloud becomes undeniable in virtually every vendor's IT strategy, Microsoft's...
changes to SharePoint are inevitable. Historically, Microsoft has been slow to fully embrace the cloud model, but it has come to understand that it and has created a two-track strategy.
Microsoft continues to sell on-premises, installed software versions, while focusing most new efforts on roughly equivalent cloud-based versions. In most cases, Microsoft will update the cloud-based version well in advance of on-premises versions because it's trying hard not to cannibalize either track.
Microsoft has committed to supporting at least one more on-premises version in 2015, but the future of SharePoint is definitively in the cloud.
Still, if you are weighing whether to choose SharePoint on-premises or SharePoint Online, there are differences. The question is whether these differences have a material impact on the solution's fit for your organization.
Big feature differences
"What is the feature difference between SharePoint Online and on-premises?" is an oft-asked question. The answer, however, is not crystal-clear. Microsoft provides an edition matrix that helps you better understand, at a high level, the features that each edition of SharePoint comprises. Unfortunately, for more technical depth, poring over application programming interface and technical deployment documentation is required. Further, the ever-changing Online continually shifts the answer by degree. However, some "big" and obvious differences would affect all organizations; these differences haven't fundamentally changed since the first Online version was introduced in 2008.
Both SharePoint on-premises and Online have search capabilities. The big difference is what their search indexes can include. Typically, when the phrase enterprise search is used, it means that the search engine in question can index multiple, disparate content sources.
In the case of SharePoint on-premises, this is true. SharePoint has long been capable of indexing SharePoint content, as well as content stored on file shares, Exchange, websites and Lotus Notes databases, among various content sources. Starting in 2007, Microsoft added the capability of indexing structured data from databases and other applications through the then-called Business Data Catalog. That feature has since matured and is now called Business Connectivity Services (BCS), and it allows virtually the same capabilities.
The same isn't true of SharePoint Online. The search engine can index all content stored in SharePoint and sources connected through BCS, but not index file shares, other websites or Lotus Notes databases. While the capability is largely constrained based on where SharePoint Online is hosted, the more fundamental difference is the controls available to administrators; the ability to define other content sources, like on-premises implementations, simply doesn't exist.
You can't read an executive publication -- IT-related or otherwise -- without stumbling across the words big data or enterprise information management. The reality is that enterprises are desperate to use the massive volumes of data they've collected to extract every advantage available. To that end, one natural place to surface that data is through SharePoint.
However, much of that valuable data is hidden away in big enterprise implementations of software from companies like SAP and Oracle. In many cases, regulatory or security constraints prevent that data from being moved to the cloud or even cloud services being connected back to the enterprise. As a result, companies are severely limited in their ability to use SharePoint Online as an aggregating portal or to present "dashboards" that use this data.
For both good reasons and bad, custom development doesn't fit neatly into the new app model (see the "SharePoint Deconstructed" section below). Examples like closely integrated Web parts, custom entity extraction (or other search pipeline additions), and connection to enterprise systems may require a more "traditional," custom development approach. This would include the now-deprecated sandbox approach or even a farm-level solution. Unfortunately, neither is effectively supported through SharePoint Online.
Make no mistake: This is largely an improvement in condition. For good reason, Microsoft changed the custom development model to avoid the dreaded "incompatible" upgrade situation and challenges in migrating custom technologies from one version to the next. But the reality is that some situations require a more coupled development model. Online simply doesn't support it.
SharePoint and Azure
Microsoft has made no secret about its plans for a universal cloud platform. It wants to be in that business, and Microsoft is clearly a cloud leader in infrastructure as a service and platform as a service, along with Amazon, Salesforce.com and Google. Starting with SharePoint 2013, Microsoft radically changed the custom development approach, casting off the "within the farm" development model, long established since the 2003 version. SharePoint 2013 introduced the "app" model, which separates SharePoint from custom technologies that customers or independent software vendors (ISVs) might construct.
Along with this change, Microsoft introduced a close relationship between Azure and SharePoint. By default, apps created either by ISVs or customers are hosted on Azure. In addition, the new OneDrive for Business feature of SharePoint natively uses Azure (under the covers) to host shared files. While in both cases customers can choose to change the hosting location, the default is absolutely Azure.
By watching the very regular Azure service updates, you'll notice a pattern. Microsoft is slowly "deconstructing" various on-premises products, like SQL Server, BizTalk, Team Foundation Server (TFS) and SharePoint, into individual services. These services are made available through Azure. Customers can then construct new technologies by using features and components previously included only in a specific product.
One recent service to surface is search. Individual products like FAST, Search Server and SharePoint have historically provided search as a feature. In the 2013 release of SharePoint, Microsoft consolidated all search functionality into the SharePoint platform. As of August 2014, Microsoft has made search available as an Azure-hosted service. This new service effectively makes search a standalone product. Users can then integrate search into any number of applications. While it may not be a fit for all solutions, it is a compelling addition to the universe of Azure services.
In addition to search, Microsoft also deconstructed TFS into Visual Studio Online, which has an interesting connection to SharePoint. Historically, TFS used a specific SharePoint Site Definition to structure software development teams, providing planning and tracking tools. With Visual Studio Online, Microsoft has shifted this capability entirely into an Azure-hosted environment, again divorcing the bit from the core SharePoint product.
In the end, it would not be surprising to see Microsoft completely deconstruct SharePoint. SharePoint is a complex platform with functionality that covers a broad spectrum of needs. Given Microsoft's behavior patterns recently, it's conceivable that SharePoint, as a monolithic product, completely disappears within two major releases and a collection of more distinct and decoupled Azure services takes its place (but that's a prediction for another article).
Taking it all in
The story of SharePoint in the cloud is unfinished. It's clear from Microsoft's public announcements that it is now a cloud-first company and SharePoint is at the front of the line in terms of this transition. But whether SharePoint disappears into a collection of services or remains a unified platform is yet to be seen.
SharePoint doesn't have to be all-or-nothing
SharePoint 2013 vs. 2010
SharePoint out-of-the-box features
SharePoint 2016 vs. SharePoint Online comparison