So it seems that with regard to Kundra’s 25-point plan and the mandate to move three applications to the cloud in 18 months that email seems to be the primary target for the first transition.  The decision to move email into the cloud is a relative no-brainer.  Email needs to be ubiquitous, accessed across a wide array of client devices, needs to scale out to support the growing community of users and demand for storage, and, most importantly, needs to be available.  So, the question isn’t should you be transitioning your email to a cloud-based solution, but instead, what is the appropriate service—SaaS, PaaS or IaaS—and deployment—private, public, hybrid, or community—model for your cloud-based email solution.

The difficulty in this decision is comparing the alternatives given that there are many tangible and intangible factors.

Software-as-a-Service (SaaS) options can be evaluated from a purely financial viewpoint.  That is, one can compare the following:

Given positive growth in the organization and taking into account requirements to scale the email solution to support the growth in users, at some point it costs more for the SaaS solution than the in-house solution (see Chart).  Also, there’s the benefit from the tax implications for moving the dollars from capital expenditures to operational expenditures and the present value of money not spent on hardware and labor that can be used for other activities.

The intangibles for SaaS solutions include trust, availability, support, user experience, accessibility, etc. Ultimately, you are relying on a SaaS provider to ensure that your email is available when you need it.  Given that email has become a critical tool for communications, lack of availability can mean loss of business, missed business opportunities or delays in servicing customers.

A larger intangible issue is how management views email.  If management views email as a standalone tool for electronic communications, then the SaaS decision becomes much easier to make.  However, if management understands that email is part of a much larger unified communications strategy that incorporates voice, video, chat/SMS, mobile and presence, then selecting a single SaaS provider becomes much more difficult as this is not a single service, but a complete integrated set of services that need to be acquired.  That is, the SaaS provider must now deliver your telecommunications infrastructure as well as your email.

The final issue regarding SaaS alternatives for email is vendor lock-in.  Given how critical email has become as means for communication, if a single vendor holds all of your organization’s email it makes it very difficult to leave that offering should the need arise.  Migrating email boxes is a very expensive effort; certainly one capable enough of wiping out any past savings that occurred from going with a SaaS vendor in the first place.  Of course, these costs will drop over time as the need arises and the process becomes more automated.

Then again, even with a SaaS email provider you are still most likely going to want to provide your users with a single means of authentication with your own internal networks.  So, you’re still responsible for building and maintaining your own identity management and authentication methods that facilitate access for your users into the SaaS email environment and not force them to have alternate identities for internal and SaaS solutions.  Of course, you could always acquire Security-as-a-Service to mange this for you.  Then again, managing proliferation of external services is no easier, and indeed may be more difficult, than managing that set of services from a single internal data center.

Platform-as-a-Service (PaaS) offers some interesting opportunities for bringing your email to the cloud.  Typically, the available PaaS offerings provide unified communications capabilities so that you can develop an integrated suite of tools for your users that includes email, chat, voice mail, paging, presence, email transcription and voice dialing.  In addition, these platforms also are open enough to integrate cyber security and authorization schemes that limit data loss and promote ease of forensics and eDiscovery.  The benefits of the PaaS alternative is that it reduces the hurdles to entry, promotes rapid deployment, can scale on demand, and can integrate with existing telecommunications systems through SIP-based protocols.  The downside is that you will most likely need to design and support your own means of disaster recovery and continuity of operations.  Unfortunately, there are very few of these platforms available on the market at this time, but I expect this will grow as more companies begin to understand this option.

The final alternative, Infrastructure-as-a-Service (IaaS) only offsets the need for you to acquire, maintain and run the hardware for your solution.  You’re still responsible for acquiring and deploying the software and paying the licensing and maintenance on that software.  In addition, you still need to develop and acquire the infrastructure for your disaster recovery and continuity of operations.  Moreover, you may not even get to control where your data ends up physically residing or what other virtual machines are running on the same server hardware.  The good news is that you will have significant control over the virtual machine configurations and be able to secure access to them.

So, transition your email to the cloud? Sure, why not? But what service model will you use?  Once you decide what service model to use, will it be a public, private or hybrid deployment?  Suddenly, this seems like a bigger decision than initially perceived.