The Inherent Risks of Hybrid Environments

In the early days of SharePoint (way back in 2006) while I was still working at Microsoft, we ran into a number of customers who were struggling with the migration of their extensive email archives and collaboration content from Lotus Notes to the new (at the time) SharePoint Online platform. We spent a lot of time working with these customers and members of the Exchange team in trying to figure out a migration strategy for these customers. After numerous migration tool vendor meetings, product reviews, interviews with consultants, and various forays into building our own technical solutions, we came to the conclusion that for many of these customers, the right path forward was to leave their content where it was.

The successful deployment of the platform in these organizations usually meant standing up SharePoint side by side against Lotus Notes (or other platforms), and as new projects were initiated, allowing the end-users to decide “Does this new project need to be associated with our legacy content and customizations, or can it be built on our new SharePoint environment?”

I recall having a conversation with Microsoft CVP Jared Spataro a few years back, possibly during one of Microsoft’s Worldwide Partner Conferences, (the one in Houston, maybe?) at which he shared a similar story in his time at Open Text. For some reason, that conversation stands out to me….I think because it was also the event where they were practically giving away the original Surface NT devices. But I digress.

From a migration perspective, this advice of “staying put until you really, really need to move” eases the pain. Migrations are rarely straightforward. But what this “best practice” of standing up a new system side-by-side with your old environment and then having end users decide whether or not to move means maintaining two (or more) platforms. For a while, at least.

I’ve run into a similar scenario over the years — sometimes in conversations about complex custom workflows and automations (and InfoPath), others with older versions of SharePoint providing basic reports and other capabilities — with no real urge to move away from them. With all of the platform advances made since then, some aspects of our “best practice” remains in force. We now have more options for moving data from legacy platforms to SharePoint (online or on-prem) using third-party migration tools, as well as powerful APIs that allow us to index and search across file shares, BLOB storage on inexpensive hardware, or a variety of cloud-based and on-prem storage options. As companies deploy Power Apps, a lot of the cloud blockers are fading away. Some organizations are even using OneDrive as a mechanism for bridging the gap between legacy and the cloud, allowing end-users to transfer content on their own, as needed.

I don’t know what percentage of organizations are still supporting old versions of SharePoint, as Microsoft does not publish this data. At community events, I used to ask my audiences to raise their hands to show which versions were still in production. I haven’t asked this in a while, but it’s been years since anyone indicated use of 2001 or 2003 (admitted to it, anyway), but I did see a couple of hands of people running 2007, and several more running 2010, with the majority 2013 or newer.

The reality is that many organizations still need to realize business value at the investments they’ve already made before moving to a new platform. On top of that, some of these legacy systems — and other non-standard, vertical-specific (line of business) apps — required strict governance standards, apart from what was managed for SharePoint and other basic collaboration solutions. And there’s nothing wrong with sticking with these old versions as long as your organization is getting value (above and beyond maintenance costs).

I may sound like an on-prem apologist, but my reasoning is simply about economics. Many enterprises have realized that while the cloud may be the future, their transition toward that future may take some time. What this means, of course, is that some of these organizations will need to maintain some very complex security and management models. As more and more cloud-based solutions are used (Dropbox, Box, Google Drive, etc) the potential risks of data mismanagement increase. While implementing a hybrid cloud solution seems like the best of both worlds — maintaining business-critical on-premises solutions while taking advantage of key cloud workloads, like using Office 365 and SharePoint Online for new team site provisioning — the reality is that hybrid solutions create massive security governance risks, and therefore require careful planning.

At the end of the day, I am a huge cloud advocate. The majority of my company’s data resides in Office 365 and Azure, or within specific workloads (Marketo, JIRA, etc), yet we support companies using on-prem, hybrid, and cloud environments. And while many of the companies and customers I speak with have similar cloud footprints, most recognize the security implications of running these hybrid scenarios and have plans to eventually move everything to the cloud. Every time I hear about another security breach, I think of all of these unsecured, non-compliant hybrid platforms out there.

Ask yourself: how secure is your data? Do you know what sensitive data is being shared between systems behind the firewall? What about outside of your firewall, on cloud-based storage systems? How much visibility do you have?

Maybe it’s time you developed a plan to move it all to the cloud.