What's your back-out plan if an Office 365 deployment is unsuccessful?

What's your back-out plan if an Office 365 deployment is unsuccessful?

When I wrote asking whether backups are necessary for Exchange Online (or the rest of Office 365), some readers responded to say "yes – because we want our data to be under our control". This doesn't really mean that they don't trust Microsoft or cloud services in general. It's simply that these companies want to have a complete copy of their data available for their use should the need arise.

Situations that they envisage include the possibility of needing to recover information from backups if a rogue administrator removes data from Office 365. Remember, Microsoft doesn't take backups within Office 365 so information is irretrievable if it is permanently removed from an Exchange mailbox or a SharePoint document library.

Another reason was touched on by J. Peter Bruzzese in a piece called "Don't let the cloud be your next data prison" when he noted "Office 365 protects your data availability, but it doesn't provide a backup that is actually yours should you decide to leave Microsoft." The important word here is leave, which brings us to the question of what back-out plan can be put in place for a company who decides that cloud services don't work for them.

Now, you'd hope and assume that a company would make their mind up soon after starting their journey to embrace the cloud. A technical issue like lack of network capability that makes it impossible for users to work with cloud-based data comes to light soon after workload is transferred. Cultural issues like dissatisfaction with how cloud support operates or the loss of control you experience over how the system operates should be quickly apparent too.

In most cases, companies who encounter difficulties address the technical issues and work out how to use the advantages of the cloud to offset the perceived disadvantages and move on. It's great if this is possible, but the cloud simply doesn't work for some. And if you're in that situation with Office 365, you have to figure out how to retrieve all of the content that has been moved to the cloud, which is when the fun and games start.

Thanks to the engineering investment made by Microsoft to enable hybrid connectivity, Exchange is actually the easiest workload to handle. You can move mailboxes back to on-premises servers as easily as you can move mailboxes to the cloud. The only downside is the amount of storage you might have to deploy to accept all those inbound mailboxes because they will have swollen in the cloud as users take advantage of Microsoft's liberal mailbox quotas.

Mailboxes are relatively easy but everything else is hard. How do you move public folders back from Office 365 to on-premises servers? The public folder migration requests that are used to move folders from on-premises servers to Office 365 have a one-way focus so that method is unavailable. You might end up spending many boring hours exporting and importing public folder content via PSTs.

If you've elected to use Information Rights Management to protect information inside Office 365 (a feature that is so much easier to implement than on-premises), you might find that it's difficult to access protected content that's moved back on-premises because it can no longer be decrypted. A hybrid configuration will help as long as you maintain a connection to the Office 365 RMS servers.

You'll have to make sure that any customization made to Exchange Online is taken back on-premises so that things like PowerShell scripts, transport rules, Data Loss Prevention rules, retention policies and tags, and so on are moved across. Again, if you're in a hybrid environment these settings should already be duplicated to ensure that the two sides of the hybrid coin remain in tandem, but there's work to be done to make sure that everything is as it should be.

If you’ve used Office 365 Groups you'll find that these objects are unsupported in the on-premises world (as are user-centric features like Clutter and People View). Without descending into the boring and repetitive solution of manually extracting documents from libraries and moving them to an on-premises file server, it's hard to know how extract the information held in all the document libraries connected to the Office 365 Groups in use within a tenant, let alone think about how to retrieve the information in group conversations, and shared notebooks. Microsoft doesn't provide export utilities for this purpose, so extracting information from Office 365 Groups will require a great deal of manual effort to recover data from the cloud.

As Microsoft notes in the Office 365 Trust Center:

"You own your data and retain all rights, title, and interest in the data you store with Office 365."

However, there's no obvious way to extract and move a complete tenant's worth of lists and libraries from SharePoint Online, data stored in OneDrive for Business, or SharePoint eDiscovery cases.

The same is true for the Office 365 Video portal, which allows tenants to set up channels that contain videos for viewing inside the company. This is actually a nice integration between SharePoint Online and Azure Media Services that is good at ingesting content without having equivalent export functions.

And if you use Lync Online, you'll have to move to Lync on-premises with all the disruption that this could cause.

Third party software vendors offer plenty of utilities to help move content to Office 365 or from Google Apps to Office 365. I haven't seen any highlight their ability to move information out of Office 365 back to on-premises servers. Given current trends, this is natural, as it would take a pretty bold decision to create a new tool for this purpose. I'll be happy to update this piece to mention tools that can handle off-boarding from Office 365 if vendors want to contact me.

Don't get me wrong. I enjoy using Office 365 and believe it is the right platform choice for many companies. Everyone hopes that Office 365 projects are successful and the signs are that most are. But it's inevitable that some will fail for good or bad reasons. Those projects need a back-out plan. In fact, every CIO and IT Director who makes the decision to embrace the cloud needs to understand what they will do if things go wrong. I'm not sure that they all do.

Follow Tony @12Knocksinna

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.