5 reasons you should adopt a hybrid SharePoint configuration by 11 community experts

254
Views

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’.)

Search

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.

Customised Solutions

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

Quite often server side code is what is considered when performing an upgrade as the lack of server side code is often referred to as a “no code” solution. However there are some customisations that can be applied through web parts in the browser such as custom JavaScript, CSS, or even SQL, all of which are items that are “developed”, can cause issues with the move to SPO. As with the server side code solutions is there sufficient documentation, that is, what requirements, technical designs, tests, etc…, exist?

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

As the content held in SPO can only exist in one (paired) location this inherently means that a geo-dispersed user base will experience some latency. While there are techniques that can be used for custom developed parts of a solution to influence its performance such as CDNs for items such as JavaScript, CSS or images, injecting JavaScript using Custom Actions early in the DOM or Local Web Storage in the browser to cache data your application relies on, list items, documents, taxonomy data are less controllable in terms of performance. For instance users performing document centric collaboration workloads will experience increased latency the further they are from the O365 host.

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.

Data Residency/Sovereignty

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.

Community Viewpoints

Andy Talbot

Security concerns are still pretty high in my own observations........and that's a hard thing to overcome!

Marc D Anderson

What I've seen is that it's usually more about "data sovereignty" or fear of putting the valuables in the cloud. People seem to have little issue with cloud-based email, whereas some documents give them the heebie-jeebies. (Never mind that they are emailing those same documents around, which usually goes through the - wait for it - cloud.)
So often they might go hybrid for the cool features and maybe some extranet sites first, if only to kick the tires. I expect over time we'll see some people moving more fully cloud, as well as people moving back on prem.

Nick Brattoli

Also, I see the smaller companies being more willing to go full-cloud, due to the low entry barrier. Larger companies tend to be more afraid, and more likely to have the people and capital to keep on-prem stuff running.

Adam Levithan

Also, remember that migrations themselves could take years. A rare but true story is licensing also can hold people back.

Matt Wade

Agreed, Mark. We evaluated doing hybrid before going all-in on O365 and it's just not worth all the necessary integrations to really /do/ it. The most fundamental issue is SPO has a different UI than SP2013! How do you explain that to people who are already so busy!? Customizations can be a setback, but it's not a bad way to get ppl off expensive (and many times outdated, lingering) custom solutions by dangling much better functionality and features found only in the cloud. Plus the price point of administration looks good to the CIO and CFO

Veronique Palmer

Being on bleeding edge technology all the time that you have no control of is not appealing to non tech companies, they have day jobs and can't deal with the constant change that comes with O365.

Prabhat Nigam

Consultant goes to office 365 and Staff in on-premise for many companies. Most of the financials, Security, Law firms, some non-profits stays on-premise. Biggest Migration of Data can end in couple of months.

Mark Macrae

Folks generally want a choice. When you give them a choice they will generally choose the best of both worlds neither wholly committed to cloud or onprem. Human nature.

Qamar Zaman

I find the amount of .net code through custom applications developed on top of SharePoint- easier to shoe horn them into SP2013 on prem than to rewrite them. The companies I've been involved with are moving to O365 from 2007/10 and have gone really crazy on .net - considering 10-30k site cols, hybrid provides a good halfway house between totally disjointed experience and the final goal.

(254)

3.73/5 (3)

Please rate this

5 reasons you should adopt a hybrid SharePoint configuration by 11 community experts

| Community, Hybrid, SharePoint | 0 Comments
Profile photo of Brian Smith
About The Author
- “Hands on” Solution Architect focusing on the Microsoft product stack and related technologies, including Azure and Office 365, having worked with C# / .NET from 2002 and SharePoint from 2003. Full software development life cycle experience, from initial client meetings and pre-sales, through development and go-live, and subsequent functional enhancements, predominately on projects using Agile methodologies.  Works with the client and implementation teams to drive out the solution that delivers to the client’s needs, balancing the technical, commercial and sometimes political factors, in green field and project recovery situations.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">