Migrating Email to a Cloud Provider? Understand How Email Architecture Works and How You can Use an Email Backbone to Your Advantage
Email is one of the core IT infrastructures for collaboration. When it must be changed—due to the end of life of a product, a move to a new product with required features, a move to a product to lower operational or support costs, or due to a merger or acquisition—the change typically involves the migration of users’ mailboxes from one system to another. In the case of the most commonly deployed groupware platform in large enterprises today, Microsoft Exchange 2003, the upgrade to the latest version, is a migration to a new system. When parallel mail systems are created, a portion of the enterprise’s email architecture must be dedicated to the routing of email messages between the two systems. That part of the architecture is usually referred to as an email backbone.
This column addresses what an email backbone is and focuses on how enterprises today can leverage an email backbone for mailbox migration, as well as migrating mailboxes to the cloud. It is critical to understand why the email backbone is an important architectural tool when dealing with the migration of email mailboxes and why enterprises need to have an email backbone as a permanent part of the email architecture.
Basic Email Architecture
The standard model for email architecture in large enterprises or those with a high degree of complexity or with extreme geographic distribution can be broken into three layers:
(1) An Internet gateway functions as a boundary security layer between the internal private network and the public Internet
(2) An Email backbone provides intra-company routing of email, the SMTP infrastructure for email-enabled applications, and provides a platform for the enforcement of company policy
(3) A groupware layer is where local delivery to mailboxes occurs. This is what most end users call the “mail system”.
Figure 1: Email Architecture Schematic
Leveraging the Email Backbone for Mailbox Migration
Although it is technically possible in some instances to glue multiple disparate groupware systems together, a more elegant solution is to rely on a core email backbone to manage the inter-system email routing in the email backbone. The email backbone, since it handling all email, even those messages not traveling to or from the groupware systems, must have knowledge of all the email recipients in the company, therefore, there is already a directory infrastructure for the email backbone. When it comes time to migrate users from one groupware system to another the following process is nearly universal regardless of the groupware systems involved:
(1) The directory is updated during the migration of the users being migrated
(2) The email for those users is queued for later delivery until the migration of the mailbox is complete
(3) The email is delivered to the users’ mailboxes on the new system.
This process assumes an on-premises infrastructure, but he same process is followed even when the mailboxes are being transitioned to a Cloud provider who will be hosting mailboxes.
Migrating Mailboxes to the Cloud
During the time that mailboxes are being migrated to a Cloud provider, the same principles apply. When users are being migrated, the email backbone functions as the routing infrastructure between those mailboxes in the Cloud and those users and email-enabled applications that remain on premises. The same process of directory updates, queuing of new mail, and then post-migration delivery and routing, applies.
The added benefit of an email backbone is that it may become a permanent routing infrastructure between those users in the Cloud and those users who remain on premises, perhaps for security or compliance concerns. It also provides for central management for email policies and high-value functions such as encryption and archiving of email, that may not be available in the Cloud offering. The email backbone is the glue that keeps disparate email systems communicating. This is particularly the case when migrating to the Cloud, because most email-enabled applications are not moving to the cloud, nor is it cost effective to rewrite many of these applications to use an Internet-based email infrastructure. In this instance, the on-premises email backbone is an imperative.
Making the Temporary Permanent
The email backbone is an important architectural tool when dealing with the migration of email mailboxes and maintaining email integrity during the migration process. In some upgrades, it is an absolute requirement, such as the upgrade from Microsoft Exchange 2003 to Microsoft Exchange 2007 or 2010. Microsoft recommends either the deployment of Edge servers with Edgesync to get the directory information unified, or the use of a third-party email routing infrastructure with directory synchronization. The implication is that this is a temporary infrastructure, however, given the on-going efficiencies of an email backbone in terms of managing complexity, providing a routing infrastructure for email-enabled applications, off-loading policy processing from mailbox servers, it makes sense to have an email backbone as a permanent part of the email architecture if one does not exist already.
