The following is a list of requirements that may lead to an organisation choosing to adopt a SharePoint hybrid configuration. It’s not an exhaustive list, but should trigger some thoughts and bring about further points for analysis.
It is worth remembering that when talking about a hybrid and the use of an on-premises SharePoint installation, it is the form of SharePoint being used that is referred to as on-premises, that is SharePoint Server 2016/2013, rather than its physical location. This means other benefits of the cloud can still be leveraged by deploying the on-premises SharePoint instance in Azure IaaS. This would need to be determined through analysis of the requirements looking to be addressed and other factors. It is possible that an implementation could be defined that utilises SPO, SharePoint 2016 deployed to Azure IaaS and SharePoint 2016/2013 deployed to the organisations data centre.
(If you are unsure about what ‘hybrid’ is then we strong recommend you check out Nick Brattoli’s post ‘The Ultimate Business Decision Maker’s Guide to Hybrid SharePoint’.)
There are limitations in the sources of content/information/data that SPO can index and serve to a user via search. For instance data held behind an OData end point cannot be indexed by SPO, however it can be indexed from an on-premises SharePoint Search service. The SharePoint Search Service enables you to crawl and index a notable amount of sources of data and content, meaning you have already be doing this or are planning to either through out of the box configuration, minor development work or (tying into item 2c below) though a third party search solution that contains custom Search Connectors.
Legacy SharePoint estate which contains custom applications with server side code
Over the years the organisation has invested in developing solutions that contain server side code, such as custom web parts, timer jobs, user controls, InfoPath forms with code behind, etc… and the cost and risk of redeveloping these solutions to work O365 (and Azure) may be high, for instance are the existing solutions sufficiently documented, that is, what requirements, technical designs, tests, etc…, exist?
Before deciding that the these solutions must stay in their existing on-premises SharePoint farms, the following should be considered
Does a solution that fits in the category require a significant uplift in functionality? If so then this might be an opportunity to re-architect them to be delivered through O365 (SharePoint and other services on the platform), Azure, and possibly other platforms/services (third party SaaS, AWS, on-premises).
Is the solution currently deployed on a version of SharePoint that has reached end of life or is approaching end of life. If this is the case the customisations should be evaluated to understand what the difference in effort is between re-architecting the solution to work in Office 365 (O365) vs. migrating (content) and upgrading (code, templates, etc…) the solution to work in a newer version of SharePoint, most likely SharePoint 2016.
If there are multiple on-premises SharePoint farms can the custom solutions from across the farms be consolidated onto one farm thus enabling the other farms to be turned off, reducing OpEx, providing an easier set of solutions to integrate into a hybrid (should they form part of a hybrid), and moving the organisation closer to being cloud first.
Legacy SharePoint estate which contains custom applications with notable UI customisations
Some web parts such as Content Query Web Parts have limitations applied to the number of them that can be on one page in SPO; any more than eight of these on a page the server will protect itself from the excessive load they will apply.
An additional potential issue for wanting to upgrade/migrate is the Modern UI that has recently arrived in SPO and the potential that at some point this could be the only option meaning that some of the UI customisations, such as those required to apply some level of branding, will need to be re-worked or removed.
These issues as a whole should not stop the migration of a solution containing such customisations to SPO but, in combination with other issues may result in a notably higher effort to migrate to SPO compared with migrating to SharePoint on-premises.
Third party products/solutions that are still on-premises only
The third party vendor’s product/solution only exists in a form that needs to be deployed to an on-premises SharePoint implementation may be in this position because they have not seen enough demand in the marketplace for them to re-architect their solution to work in O365 (and Azure) to make their solution work in O365.
It may be the case that the third party vendor has re-architected their product/solution to work in O365, but as there is an upgrade and migration process that will need to be gone through as part of moving the solution to O365 it is not something that the organisation is able/prepared to undertake at the given point in time.
Another reason may be that the third party vendor’s product/solution relies on the capabilities or components that an on-premises SharePoint implementation provides, for instance a third party search solution that contains custom Search Connectors.
Performance issues related to latency
Before deciding that the performance of SPO isn’t sufficient, the following should be considered
Undertake some performance testing to determine if there is an O365 region that could be deployed to that provides an acceptable balance of performance for your users based on the dispersion of your user base; how many people are in each location and can you tolerate lower performance where there are fewer users?
If a 10MB document takes 15 seconds to download to users on the other side of the world is this an issue if it takes say 12 seconds to those located closer to the O365 host?
How is your organisation’s network performing? Deploying on-premises could result in not too dissimilar results to O365 for users of various solutions deployed to SPO.
Having to guarantee greater than a 99.9% SLA at key periods
There may be solutions that are to be deployed to SharePoint that have certain periods of the day/week/month/critical stage of a business process whereby an SLA greater than 99.9% is required. What the 99.9% SLA for SPO means should be clearly understood and understand that there are elements of the service that can experience service degradation, but not service outage and the 99.9% SLA is still met.
Before deciding that SPO’s 99.9% SLA isn’t sufficient, the following should be considered
Can the organisation provide a 99.95% or 99.99% SLA with an on-premises SharePoint implementation 365 24×7? If the organisation can, what is the cost of providing it vs. the cost of potential losses in productivity or future revenue.
If there is service degradation of SPO what elements of the service can the solution tolerate not being 100% available; Microsoft have stated a 99.98% SLA being achieved for various periods this year for the O365 platform.
Are there business processes that could be put in place to mitigate a service degradation/outage? These processes could leverage other pieces of technology such as ensuring someone has synced the key documents using OneDrive For Business on a regular basis during the critical stages of the business process.
An often discussed and often misunderstood subject, where in some cases there is a perceived fear of losing control of ownership of the organisations information comes before understanding the actual legal position the business is in. There are industry sectors who’s information must adhere to legally binding Data Residency/Sovereignty policies, the question is how much of this information would be classified as having to adhere to these policies.
Before deciding that the Data Residency/Sovereignty issues can’t be overcome, the following should be considered
Be certain you know the exact details of what data falls under Data Residency/Sovereignty constraints, as opposed to speculation, ensure the data is classified and the related policies are put in place.
How much data is affected, what laws apply to the data (these vary by country), how many users need to use the data, and what is the value associated with the tasks that the users perform that utilises this data. Once this is understood there needs to be an assessment of whether that data/information/content belongs in SharePoint or should it be stored somewhere else. For instance, if there are 20 users in Germany who need to work with such data, but the data is only a small subset of all the data they need to use and it can be easily isolated/separated from other data, and not add excessive effort to the tasks the users are performing with it, then could the data be held somewhere other than SharePoint? If SharePoint is felt to be the location for the data to live what would be the anticipated ROI of putting an on-premises SharePoint implementation in place for this scenario, but don’t forget the TCO as part of the ROI calculation. This will tell you whether SharePoint is suitable for storing that data/information/content belongs or that should it be stored somewhere else.