Skip navigation
Not always straightforward to calculate the costs of moving on-premises email to Office 365

Not always straightforward to calculate the costs of moving on-premises email to Office 365

I received lots of comments and email after I posted details of my support experience with an Office 365 upgrade from Wave 14 to Wave 15, which seems such a long time ago now. Thankfully everything was restored to full health once the problem was escalated within Microsoft and I have enjoyed using the Wave 15 version of Office 365 ever since. The service has also functioned pretty well in the intervening period, which is a relief.

I've been using Office 365 since Microsoft launched "the service" in June 2011. Looking back on my experience over that time, I believe that the service has delivered or even exceeeded the level of service that I expected at an excellent price point. However, many commentators continue to hold to the view that on-premises applications are cheaper to run than their cloud equivalents. One comment to my post described salespeople quoting $300K to deliver cloud services for 2,700 users where a company paid $150K to an administrator to run equivalent on-premises services and asked where any savings existed. Another comment cited an Office 365 quitation of $500K for 3,000 users and said that they could provide an on-premises service more cheaply. Although I don't have the exact details of these quotations, it is possible that the variation in cost per user is explained by the prices for the different Office 365 plans that are available. Considerable difference exists, for instance, if you include the desktop Office applications in the calculations.

In any case, I think that comparing the salaries of the current on-premises administrators to the fixed annual cost proposed by a cloud vendor is too simplistic to make a proper decision as to which platform is right for your company. Let me explain why.

First, the administrators as described are clearly very competent individuals because they take care of a range of applications from Exchange to BlackBerry Enterprise Server to Symantec Enterprise Vault. These people clearly work hard for their money. My problem is that the administrators seem to represent a single point of failure for the IT infrastructure. There is no mention of how things operate when they are on leave, being trained, attending conferences, or sick. Nor is the cost taken to recruit a replacement should they decide to leave. In short, I think the staff cost as cited is unrealistic and needs to be increased to make a fair comparison.

Second, costs are computed at a single point in time. I have no doubt that it might be cheaper for a given company to run on-premises services over the next year more cheaply than if they use a cloud service such as Office 365. That is, if everything goes well and no major outage occurs that incurs more cost for the company. But IT systems have a nasty habit of costing more as time goes by. Components wear out or break and need to be replaced; applications need to be upgraded; or new demands for functionality arise within the business (perhaps due to government or other regulations).

It’s better to analyze system cost over a five or seven-year period as these will be more accurate and a better guide for your decision. To make sure that all bases are covered, you should increase the cost for cloud subscriptions to reflect the inevitable price hikes that the vendors will make over the period. I think it fair to predict that cloud subscriptions will increase by 25% over the next seven years. If the cloud vendors surprise everyone by keeping cost down, the surplus will take the slack of any other costs that you fail to include now. If price hikes are higher, we might all need to look for another job.

You also need to include one-off costs for the cloud platform that salespeople seldom mention, such as migration expenses, changes in network configuration and equipment required to reflect the change in traffic patterns as internal connections move to Internet connections, or the need to rewrite applications so that they function with the cloud platform. Migration costs might be minimal, as in the case of a weekend move of accounts from on-premises to the cloud. On the other hand, migration has a nasty habit of being more expensive than estimated if the process lasts for more than a few weeks. And costs are different again if you decide to run a hybrid environment.

Support is another cost that is often missed. You might have a support infrastructure in place today that costs a certain amount to process support tickets on an end-to-end basis. I bet that these costs will change if work is moved to the cloud if only because some of the support activity becomes invisible when it disappears into the cloud (hopefully to reappear with a fix). It's also fair to say that dealing with cloud support can be intensely frustrating because it often seems to be an amorphous blob that resists any attempt to engage. All in all, it’s important to factor new a support methodology into the equation. Change in IT systems always costs and you cannot expect a transition from on-premises systems to a cloud platform to be free and painless.

Third, although I had a bad support experience (a fact that Microsoft has acknowledged in several private conversations), the fact is that Office 365 did not miss a beat in terms of providing a service to end users. Outlook Web App and Outlook continued to send and receive email. SharePoint sites still stored documents. Lync continued to participate in online conversations. The problem was with a background process controlling migration from one major version to another but it only affected some administration tools. The Exchange Management Shell continued to run as did most of the new Office 365 Admin interface. In on-premises terms, the problem was equivalent to the issue that emerged after Microsoft released IE9 when the Exchange 2010 Management Console (EMC) sometimes would not close down properly due to an issue with a component shared between IE9 and MMC. In short, irritating but not critical. My problem was with the way that the support call was handled rather than the software itself.

Last, some contingency is required to cater for the scenario where your decision proves to be flawed and you need to execute "Plan B" and reverse direction. For some companies, getting to the cloud is painful, costly, and takes a lot of effort. You can double the pain, cost, and effort to move back to on-premises simply because this is an uncommon activity that is not well understood or accommodated by the cloud vendors. You'll probably do some trailblazing and might even, as was the case with the experience reported in the comments to this article, be forced to use PSTs to move back. What a horror!

All of this goes to prove the total futility of having a discussion with anyone selling cloud services if you do not have command of the total cost picture for your current IT environment and the likely expenses that will be incurred to make the transition. It might be that moving to the cloud is the right decision for your company. Equally, you might be better off staying with on-premises software. At least the discussion will be based on fact rather than the modern equivalent of snake oil.

Happy New Year!

Follow Tony @12Knocksinna

Hide comments

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.
Publish