The need for a cloud Plan B


For most important decisions that you take in life it’s wise to have a Plan B. Something that you can do to reverse course should the unexpected occur and you need to revert to a previous position. And so it is with the cloud, an option that is being embraced with increasing conviction by many companies for different reasons, with perceived cost savings being high on that list.

But, I wonder, as I see companies rush to move workload to Office 365 or Google Apps or applications to Azure or Amazon Web Services, is their Plan B? What, for instance, will they do if ISPs struggle to cope with an ever-increasing volume for Internet traffic? I don’t think that the Internet is “full” or that a shortage of IPV4 addresses will cause real problems, at least in the short term, but it is conceivable that network infrastructures could come under real strain in different parts of the world over the next few years.

And then there’s support, which remains the Achilles heel of all cloud services. From a business perspective, I understand why customers are forced through the interminable question and answer routine from first-tier support. From a technical perspective, I understand why it is necessary to be so careful to avoid making any change within a datacenter for fear of knock-on effects on other tenants. But I fear that the combination creates a situation where customers are frustrated at the speed of problem resolution and the perceived quality of the interaction with support personnel.

I’m sure that the cloud support personnel who work the phones are frustrated too. They are constrained about what they can actually do, even when they work at the second tier and handle escalated calls. Because every tenant is unknown to the support agent, each call begins with an awful lot of information gathering, much of which seems unnecessary to the customer. And if that information doesn’t reveal a solution in a problem database, some inspired guesswork is all that can be done before a call eventually winds its way through to engineering.

Support doesn’t always flow smoothly in an on-premises environment, but at least all of those involved know the details of the environment and are aware of the background and history of the systems that are involved. A degree of closeness exists with on-premises debugging that simply cannot happen when dealing with cloud support, which can then lead to frustration and dissatisfaction.

The continuing debate about government snooping and what traffic three-letter agencies might or might not be intercepting and examining is also not helping to increase confidence and trust in cloud systems. Microsoft has just issued a document titled “10 reasons to trust Microsoft in the cloud” where the largest section is devoted to the strong stance they have taken over government access to data. I guess this proves how concerned Microsoft is on this point.

So it’s possible that despite the delivery of a solid SLA over the last few years, the promise of ever-changing or “evergreen” technology, and the flexibility of cloud systems in terms of their ability to deal with workload peaks, some companies will decide that their Plan B is to revert to on-premises servers.

The question then is “how to move from the cloud”? Microsoft and Google provide all sorts of help to move work to the cloud but little is said (naturally) about the reverse. In fact, Microsoft has an advantage in this area because of the work that they have done in Exchange 2010 and Exchange 2013 to facilitate hybrid connectivity. Moving email back to on-premises is largely done by transferring mailboxes back, ensuring that mailflow is handled by on-premises servers, and then breaking the connection.

Even after moving Exchange back on-premises, a solid case can be made to retain the Office 365 tenant to maintain flexibility and future options (you wouldn’t want some other company to come in and take over your tenant) and perhaps to handle other workload such as Lync.

Of course, Exchange’s hybrid connectivity only deals with one part of Office 365 and separate (manual) arrangements would have to be made to transfer SharePoint and Lync workload back to on-premises servers, should you decide to take this action.

Don’t take this as a definitive statement on how to move email off Office 365. Clearly, if you decide to make the change, you’ll do the necessary planning and testing to ensure that the move goes smoothly.

No manager likes to be forced to reverse course on a strategic IT decision. So much energy, time, and political resources have been expended to move to the cloud that reverting to on-premises servers will exhibit all the signs of a failure, and no one likes to be associated with those kind of projects. However, sometimes you have to bite the bullet and do what is right for the company.

Moving to the cloud is absolutely the right course for many companies to take and I remain a happy Office 365 user. But choice is good and flexibility is great, and having a solid Plan B in your pocket is a great comfort – and absolutely something that you need to consider.

Follow Tony @12Knocksinna

Advertisements

About Tony Redmond ("Thoughts of an Idle Mind")

Exchange MVP, author, and rugby referee
This entry was posted in Cloud, Exchange, Exchange 2013, Office 365, Technology and tagged , , , , , , . Bookmark the permalink.

One Response to The need for a cloud Plan B

  1. Lee says:

    I have worked with several customers in the last months moving back to Exchange On-Premises from Office 365. Also in the last week several customers wanted to move data OUT of Azure due to recent Outages.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s