In “Moving Exchange to the Cloud, Part 1,” I discussed the changing competitive landscape for Microsoft Exchange Server and the engineering effort in Exchange Server 2010 to create a version of the software that is suitable for cloud-based deployments as part of Microsoft’s Business Productivity Online Standard Suite (BPOS). In this article I discuss some of the challenges companies face as they determine whether cloud-based services are suitable for their purposes.
Companies that are considering moving their Exchange-based email services to the cloud have many things to consider. Some companies are ahead of the game, because they’re already using the Internet to replace expensive dedicated connections between their company network and a hosting provider. By exploring their own variation of the cloud, they can better understand the challenges they will face if they truly move to cloud-based services. Other companies might never transition from inhouse servers because of their overall conservative approach to IT, fears about data integrity, regulatory or legal compliance requirements within certain industries (e.g., the FDA requirement to validate the systems that pharmaceutical companies use for drug trials), the unavailability of high-quality or sufficient bandwidth in certain geographic locations, or because they operate in countries that require data to stay within national boundaries. Some companies might be chomping at the bit to move to Microsoft Online Services because they’re running older versions of Exchange Server and they see cloud computing as an effective way to upgrade their infrastructure.
Regardless of how eager (or reluctant) your company might seem to embrace cloud computing, you need to ask several questions to evaluate whether your organization is truly ready to operate email in the cloud. You need to consider hosted email options, user needs, support responsibilities, application integration, and cost. In addition, you should be aware that hosted email services simply might not be the best solution for your organization.
Hosted Email
BPOS includes two flavors of hosted Exchange: dedicated and standard. The dedicated offering is available only to customers that have at least 5,000 mailboxes—probably because creating a dedicated environment with network, hardware, Help desk, security, and directory synchronization components on any smaller scale than this just isn’t worthwhile. The standard offering uses a multi-tenant infrastructure to support mailboxes. All the mailboxes are hosted on the same set of servers and use the same directory (i.e., Global Address List), with logical divisions that make the mailboxes and directory appear to be separate.
Microsoft promises 99.9 percent scheduled uptime for data centers that currently run Exchange Server 2007 with a planned upgrade to Exchange Server 2010. Note that Microsoft already offers Exchange 2010 as a hosted service to customers in the educational sector as part of Exchange Labs; this approach has let the Microsoft development group test and prove the code during Exchange 2010 development to ensure that it’s suitable for large-scale hosted deployments.
Standard hosted Exchange offers several add-ons for an additional cost; these options include a mailbox capacity upgrade from the base 1GB, BlackBerry support, archiving, and migration from another email system. The standard offering supports Windows Mobile 6.0 and later devices, Outlook 2007, Outlook 2003, Outlook Web Access (OWA), and Entourage; it will also support Outlook 2010.
The dedicated offering is more flexible and customizable, because it’s committed to just one customer. This service includes options such as business continuity and disaster recovery.
List prices vary from country to country. Microsoft announced in November 2009 that it would offer BPOS for $10 per user per month (including Exchange, SharePoint, and Office Communications Server—OCS). The price reduction was intended to allow Microsoft to compete head-to-head with Google Apps Premier Edition, which starts at $50 per user per year plus add-ons. However, the new price came as a shock to many hosting partners because it makes a substantial cut in the margins available in the hosting business. The price war between Microsoft and Google will continue and might further lower mailbox costs.
Because Microsoft designed Exchange 2007 for traditional deployments, it isn’t surprising that some of the more advanced features, such as transport rules, rights management, and unified messaging (UM), don’t work in hosted environments. Microsoft expects to be able to support these features in Exchange 2010 because this version was engineered to support multi-tenanted hosted deployments. Exchange 2010 also has an improved distributed management model that leverages PowerShell 2.0’s remote capabilities to let administrators control their data running on servers in Microsoft data centers.
Users
Before you decide to move your email services into the cloud, you should consider whether you have any user groups with special needs that must be met. For example, companies often take special measures to ensure the highest degree of confidentiality and service for their most important users, such as executives. They place these users’ mailboxes on specific servers that are managed differently than regular systems. Administrative access is limited to a small set of administrators, the servers might be located in different computer rooms, and special operations procedures might apply for backups and high availability. Although you can expect Microsoft to secure data as it moves to and from clients on your network, over the Internet, and to servers in Microsoft’s data centers, data security will remain a concern as you transition from an inhouse system to the cloud—especially in the case of highly confidential data such as that contained in executive email files.
Another issue to consider is how your users work together. For example, can users continue to enjoy delegate access to calendars and other mailbox folders in a mix of inhouse and cloud deployment? Or do you have users who need to share data on the same platform? Is the number of calendars that a user can open limited? Do you have shared mailboxes, resource mailboxes, or mailboxes used by applications? These questions don’t yet have good answers, because there still isn’t a lot of experience in deploying and managing large-scale Exchange organizations that use BPOS. However, these are the types of questions you need to ask to better understand your users’ requirements, from basic mailbox access to sophisticated use of advanced Outlook and Exchange Server features.
Support
Negotiating cloud services involves establishing a service level agreement (SLA) that describes the level of availability of the service (e.g., 99.99 percent uptime), explains how the provider will handle outages, and outlines the financial compensation due if the service doesn’t meet the contracted uptime. Simply establishing an SLA is easy; monitoring end-to-end performance for email and understanding the roles that local and cloud support play are more complicated endeavors.
Your company provides its own local support, which typically includes the network infrastructure (e.g., connectivity to the Internet, client software, integration with other applications that depend on email). The service provider supports the services it provides. The majority of support activity occurs locally; contact with the service provider is necessary only when the service is unavailable for an extended period (e.g., the August 2008 Google Gmail service outage). Because the Internet connects your network to the cloud, you can expect transient network hiccups that cause clients to lose connectivity from time to time—after all, no one is responsible for the Internet, and no ISP can guarantee perfect Internet connectivity. (Which, incidentally, is why Cached Exchange Mode is such a valuable Outlook feature.)
Even networks that are under a single company’s control still experience problems on occasion. Administrators must understand where local problems are likely to occur and know how to quickly address them, before escalating problems to the service provider. For example, an outage might occur with the provider that connects your network to the Internet, a firewall or router might fail when it becomes overloaded with incoming or outgoing connections, or a systems administration error might block traffic outside your network.
Moving your email to the cloud prevents you from having a full end-to-end picture of the connections between your clients and the mail server, as well as limits your control to only the parts of the network that reside inside your firewall. Users typically hold the local Help desk accountable if they can’t access their mailboxes—which creates a difficult situation if the local administrator can’t trace the path of a message as it flows from client to server, or can’t verify that all the connections are correctly authenticated. In fact, because there are so many moving parts that could fail, including the Internet link, it’s difficult to hold a service provider to an SLA unless you have unambiguous proof that the cloud service failed. Experience will prove how easy it is to manage and measure end-to-end service availability in the cloud. For now, there’s a weakness in management and monitoring tools, including the ability of these tools to peek inside the cloud data centers, to allow administrators to verify that an SLA is being met.
Applications
Exchange is often integrated with other applications, including Microsoft applications such as SharePoint and OCS, and applications from other major software providers such as SAP and Oracle, as well as home-grown applications built on top of Outlook or Exchange using a variety of APIs ranging from WebDAV to Exchange Web Services. If you move to a cloud-based implementation, you must determine how to handle all your applications that depend on email.
The solution is simple in some cases—for example, online versions of SharePoint and OCS are available as part of BPOS, so you can just replace an inhouse implementation with a hosted implementation (assuming that you haven’t customized your applications to add elements, such as your own web parts for SharePoint). Moving custom applications into a hosted environment may or may not be possible, depending on what you’ve actually coded. Unified communications (UC) also poses challenges because of the number of different PBXs and other communications devices in use. The standard delivery provided by an online service might not be able to accommodate your telecommunications infrastructure, in which case you need to continue to run telecommunications inhouse or look for another partner who can support your requirements.
Anyone who has been through a platform upgrade can tell you that the IT department usually underestimates the number of applications in use within a company. Of course the IT department is aware of headline applications that they are responsible for, but they might not know about applications developed by individual users or workgroups that are now part of the business processes. These applications might include Excel worksheets, Access databases, or web-based systems used for various purposes. IT administrators often learn of these applications only when they upgrade the client or server platform and users later complain that their favorite applications no longer work.
In considering Exchange’s interaction with applications, you must also consider public folders. Although Microsoft has indicated an intention to eliminate public folders from Exchange since 2003, customer demand has forced the company to commit to public folder support until at least 2016. Some companies have thousands of public folders holding gigabytes of data to archive email discussion groups or store sophisticated workflow applications. Determining how your organization’s public folder implementation will function in the cloud can be a complicated process. For example, can a mailbox in the cloud access the contents of a public folder on an inhouse server? And if the public folder uses a forms-based application, can that mailbox access the form and load it with the correct data to allow users to interact successfully with the application? It’s inconceivable that Microsoft will allow companies to migrate public folders into Exchange Online, because the notion of support for customizable applications runs contrary to the ethos of a service delivered through a utility-based multi-tenant infrastructure—that is, a bounded set of functionality delivered at a low price point, which is achieved on a massive scale only because everyone gets the same service.
The same problem rears its head when you consider aspects of other Microsoft applications, such as OWA customizations (e.g., changing the logon page to display your corporate logo) or SharePoint web parts that are necessary for an application to run. Utility services are just that—a utility. You wouldn’t ask your water company or electric company to provide a custom service, and you likewise shouldn’t expect Microsoft to deliver a customized form of Exchange or SharePoint from its utility service. Perhaps in the future Microsoft will allow companies to customize certain aspects of online services, but I don’t expect this trend to start anytime soon.
Cost
One of the main advantages of moving into the cloud is reducing your hardware costs, because you’ll no longer have to purchase servers and storage for hosting applications. In addition, you’ll save money by paying less in software licenses for your servers. Of course, some of your recovered expenses will be offset by the monthly subscription fees you’ll be paying for each mailbox. Additional costs might include increasing the size and speed of your network connection to the Internet.
Your initial Internet connection is based on the volume of traffic you expect to generate; that volume will certainly grow if you move your email into the cloud. Mail traffic that previously stayed inside the organization will have to be transported to Microsoft and perhaps back to your network. Directory synchronization and other administrative traffic will make additional demands. In addition, moving mailboxes during migration will tax your network connection’s bandwidth. Before you plunge into the cloud, you need to ensure that your network connection can cope with the additional traffic. You might also need to upgrade your infrastructure to handle the increased load of authenticated connections flowing into and out of your company. For example, you might need to upgrade your firewalls, routers, or other network components. In addition, you might need to purchase special software to handle network monitoring and security.
Finally, you need to set aside a budget for all the work necessary to move mailboxes and other data to the hosted service. Basic processing such as directory synchronization is unlikely to cause many problems because it must be done for every hosted implementation, but you might have some special needs. For example, if you have a link-up between Exchange and your HR system so that a mailbox is automatically provisioned when a new employee joins the company, you’ll need to validate that this process works with the hosted service. You also need to work through common procedures such as recovering mailbox data from backup to understand how this task will be accomplished with a hosted server. This extra work takes time and effort that you need to budget for.
Contingency Plan
You need to consider the possibility that you could run into problems with a cloud-based implementation and decide to switch back to inhouse services. For example, the service might not deliver the functionality that your users require. You might also discover that the service costs more than you expected. Or perhaps your company will be sold to another company that has a successful and cost-effective inhouse deployment of Exchange that the new company wants to continue using. Finally, you might just decide that transferring email to Microsoft Online creates a lock-in situation that you aren’t happy with.
Regardless of the circumstances, it’s a good idea to determine your back-out plan in advance. Consider the different scenarios that could occur over the next five years and outline your response to each scenario. Even though your initial approach might be flawed and incomplete, you’ll at least have a starting point for addressing particular problems. In addition, just thinking about how you might retreat from the cloud may very well cause you to rethink how you will enter the cloud in the first place. You might think of possible problems that you need to address in your initial implementation. For example, ask yourself how quickly you’ll be able to move mailboxes back to an inhouse infrastructure if doing so becomes necessary. Another thing to consider is that although you won’t need as many messaging administrators to support a cloud solution once the migration is complete, you might want to retain some of your inhouse messaging experts just in case you decide to reverse course, as well as to monitor the hosting provider’s delivery to ensure it meets the established SLA.
Future of the Cloud
Cloud services are already here and will play a big role in the future delivery of IT services to end users. The question is how quickly organizations will be able to embrace the cloud and what challenges they’ll encounter along the road. The decision to use an online email service will be easy for some organizations, especially those that either don’t already have an existing email service or haven’t customized their current email service. Moving to a hosted service such as BPOS will also be easier for small companies, whose requirements are typically straightforward and whose financial staff will embrace the prospect of a known cost for mailboxes. Transitioning to the cloud becomes much more complicated the longer an organization has been using email, the more mailboxes the company supports, and the better email is integrated with other applications. In some situations, a standardized online service might simply be too utilitarian to meet your needs, and a more traditional outsourced option (including one that leverages cloud principles to reduce cost) or inhouse deployment will be a better solution.
