In my last post concerning the functional and financial benefits of moving email to the cloud, I spoke to the theoretical issues in making such a decision. However, when it comes to getting down to brass tacks, the theoretical is going to get you only so far. In other words, although it’s important to set goals or guidelines, they won’t do much to ensure the success of your cloud adoption or migration initiative. But fear not, as promised in my initial post on why email is a good place to start when moving to the cloud, I’ll go over some more specific points of interest and some caveats as to your cloud-hosted mail strategy.

Upon deciding to move your email to the cloud, an obvious first step might be to decide what pieces of the puzzle to actually move. For instance, you have mailboxes, message archiving, message filtering, mobile delivery, security, and disaster recovery, all to be concerned about. Additionally, while on the subject of subdividing these functional elements, start to think about which users in your workforce need access to what. Chances are that you and your team have already done this. However, now is a good opportunity to revisit and polish your segmentation, as well as revisit your quotas-particularly those users with extremely restrictive caps or unlimited thresholds.

When it comes to capacity it’s probably a safe bet to be ultra-conservative, as most cloud providers offer the ability to easily scale resources if more space or CPU is needed. But even though you can always scale down, it’ll certainly be more cost-effective to start small. Furthermore, I wouldn’t be too concerned about loss of user functionality, or getting bombarded with snarky support calls asking why a limit has been exceeded, as resources can be scaled overnight.

Your decision as to what parts of your e-mail system to move to the cloud should hold great weight in the type of provider you are to choose. Generally, cloud hosted e-mail falls into three basic categories, or what might be dubbed as all-in, hybrid, and in-parallel.


The all-in hosted approach is where the entirety of your data and at least the server-side of your software reside. Although both cloud providers and third-party vendors alike talk-up their all-purpose migration solutions, remember that it’s much easier to adopt this kind of hosted email (rather than migrate), especially in the case where the service is purely SaaS.


The second class of cloud providers offer a hybrid approach, where certain components of e-mail are run in the cloud, while others run on-premise in your own data center. Most commonly you’d store your mailboxes on-premise, while archiving or backing your data in the cloud. However, there are a number of cloud providers that offer relative flexibility when it comes to choosing which architecture your software is to be staged upon. Just remember, nothing says that you need to limit yourself to just a single cloud provider.


The third and last type of cloud provider that I so cheekily call “in parallel” concerns running an analogous set of services both on-premise and in the cloud, as distinct deployments. For example, you might run a more resource-intensive or feature rich e-mail system for executives on-premise and relegate your more casual users to using a cloud-based e-mail solution. Although I feel like certain situations warrant this kind of setup, I also feel that it might also add an additional layer of complexity, especially when the on-premise and cloud-based systems are inherently different (based on different platforms or versions). Nevertheless, it could serve as a good exercise in adopting the cloud, as well as serve as a proving ground or business case for future cloud projects.

Selecting a provider

In terms of actually selecting a provider, given the various types of providers, as well as the diverse level of functionality they can offer, I’m not going to simply list all the cloud providers out there. Instead, I’ll leave you with two bits of advice as to what to look for when evaluating candidates. The first, as described above, is to segment the various parts of your e-mail system so you can (1) decide what type of architecture would make most sense to use (all-in, hybrid or in parallel), and (2) be able to correlate each part with what a particular cloud provider could actually deliver. Clearly, if a cloud provider is only able to afford you with half of the items on your list, the provider is most likely not the best of choices, or you know you’re at least restricted to a hybrid or in-parallel type of framework.

The second bit of advice is to only go with providers that offer complete price transparency. Although this has become something of a staple amongst cloud providers, especially larger shops like Microsoft, Amazon, and Google, make sure you can fully realize the cost and value the cloud solution can present. Furthermore, if you have any questions about a specific pricing model, the cloud provider should be able to assuage your concerns. Outside of these two basic indicators, be sure that you can scale and easily jump ship (switch deployment types) if necessary.  Good luck!