Handling email domains during an Office 365 Tenant Migration: Part One
Mergers, acquisitions, and divestitures are commonplace, and a potential problem that sooner or later many Office 365 administrators will need to overcome.
When you set up Office 365 for your organization, you are a tenant within their environment – all the resources you own, including user accounts, mailboxes, file data, chats, and additional data like your own email domains belong to you. It is your organization’s responsibility to manage that data once in Office 365, and that control sets it apart from other services as it provides a similar degree of flexibility as you get within an on-premises environment. As I say to many new Office 365 customers, you don’t have to worry about the patching and recovery anymore, but you’ll still manage the day to day administration of services like Exchange, plus all the other great services you can choose to roll out.
However, there are certain restrictions placed upon what you can do. Within your own email server, you can add email domains without restriction, whether you own them or not. With Office 365, this isn’t so, and to ensure that each tenant has its own clearly defined boundaries, email domains cannot be shared between tenants. Like on-premises email systems, you must perform a migration of data if you want to move data between two separate environments.
These restrictions present a challenge if you are tasked with moving email (and other data) from one Office 365 tenant to another. You cannot share a domain between two different tenants, meaning you need to consider how you will ensure that email routes correctly when you migrate data across.
It isn’t just about email
Before we dive into purely email routing, it’s important to remember the wider context of how email domains are used across the wider Office 365 suite, and the other data and resources that need to be considered during a tenant to tenant migration.
The term custom domains are used within Office 365 to relate to the internet domain names you register within Office 365 in addition to the default onmicrosoft.com domain. These aren’t necessarily just used for your email domains. Sign-in to Azure AD, and therefore Office 365, uses a login ID that follows the User Principal Name format, which like email, follows RFC 822. For simplicity’s sake, most organizations will ensure that the login ID matches the user’s primary SMTP address. Generally, this means that during a tenant to tenant migration the user’s login ID will need to be considered and, in most circumstances, may need to change.
Whether the change to the login ID is user-impacting very much depends upon the way sign-in is configured. Organizations utilizing Azure AD join, Seamless Sign-In, or AD FS alongside Modern Authentication may see minimal user impact as the user will be signed in from their PC automatically. But for most organizations – especially those with a mobile workforce – changes to the user ID will have an impact. Oftentimes this is a consideration rather than a major issue because most tenant to tenant migrations will also include some form of identity, and PC/mobile device changes anyway. For example, as part of an acquisition, the users from the purchased organization may be issued new Active Directory login IDs and new devices.
Perhaps more crucially, the work that many organizations have performed to get best value out of Office 365 may present problems during a tenant to tenant move. Office 365 includes a multitude of services and most organizations make use of OneDrive, SharePoint, Microsoft Teams, Skype for Business, Yammer and ancillary services like Microsoft Planner, Stream and others. These need to be considered alongside an email migration – especially if Modern Attachments (where the attachment is stored in OneDrive or SharePoint) is widely adopted.
A cloud-specific problem
Back in the on-premises world, we have the flexibility to do whatever we choose. By following sensible methods, it is possible to share email domains between Exchange organizations (and other email systems). For example, in the diagram below we have chosen that Exchange Org 1 is the authoritative email system for the Contoso.com domain. Internet MX records are directing email to this environment and it holds both mailboxes and contact records representing all email addresses within both Exchange organizations. Most likely a Send Connector will route email for those contacts to a secondary email domain space in the second Exchange org, and the second Exchange org will route all unresolved Contoso.com email across to Exchange org 1.
Due to the flexibility of the options available, we could accomplish this in other ways; we could have both organizations as non-authoritative and have an anti-spam solution act as the definitive source, with connectors between both; or we could have opposing contacts between both organizations allowing a consistent Global Address List and configure both as authoritative for the domain. There are a large variety of options available.
Not so with Office 365. We cannot configure two Office 365 tenants with the same email domain, which means that although we can use contacts to forward mail across to a different tenant, we cannot register that domain in the other tenant. This means that it is difficult to bring across Primary SMTP addresses as we migrate – and that we need to perform some advanced configuration if we wish to ensure mail routing works during any required coexistence.
What do organizations need during tenant to tenant migrations?
Although the capabilities are limited within Office 365 when performing tenant to tenant migrations, that’s not to say business requirements match what Office 365 can do.
Naturally, as no capability to migrate data tenant to tenant exists, a third-party tool is required to accomplish this. The tools on the market vary in their capabilities with some better than others.
For SMTP email, however, there’s not a boilerplate solution. That’s because the business requirements differ from Office 365 customer to customer. They fall into the following general scenarios:
- Retain the email address as a secondary address. A company has been acquired and on day zero or soon after, the acquired company will take on the purchaser’s branding and during the email migration, email addresses will change to the purchaser’s brand.
- Retain the email address as a primary address. The acquired company will retain its own brand after the migration, and the purchasers’ email domain may not even be required as a secondary address.
- Don’t migrate the primary email address. The company is divesting a division. It may then take on its own brand, or the brand of the company it is being sold to. The primary email domain won’t be migrated, but there may be an agreement to forward email for a period afterward.
Additionally, business requirements may drive two different scenarios for migration:
- Long term coexistence – Two companies are merging, and it will take some time to work out the details, but a sharing will be required. This could be a shared global address list, an element of sharing and short-term migration of resources to the main “corporate” entity.
- Cutover or a fast migration – No coexistence is desired. Perhaps this is due to divestiture and on “day one” the divested division will need to operate independently, or perhaps there is a desire from the business to bring in the acquired company very quickly – particularly common with small acquisitions.
Most of these scenarios are readily dealt with – at least in the context of email.
Naturally, if we choose not to migrate an email domain between tenants, co-ordination of temporary email forwarding from the source Office 365 tenant to the destination Office 365 tenant will be the largest of our woes. This can be accomplished by placing forwarding on the mailboxes to the new domain, then converting them to contacts post-migration for whatever period needed.
If Primary SMTP addresses will be retained only as secondary addresses after mailboxes move, then this is also relatively straightforward to manage. During the migration, forwarding can be used from the source Office 365 tenant as above.
As described below, the challenge of moving the domain remains – a period of the domain existing in neither Office 365 tenant will exist; however, it becomes a lower risk operation as users begin to communicate using their new addresses, and significantly less complex as only inbound email needs to be considered.
If longer-term coexistence is required, then Office 365 does support the mechanisms to allow functionality such as external sharing and availability to function. A cross-organization global address list is often the key to this, but it must be aware of, and work in co-ordination with, migrations of resources. For example, when a mailbox and associated user is migrated from one tenant to another, the source mailbox must be converted subsequently to a contact type object to ensure that the correct location is checked for up to date availability.
The second part of this blog continues by exploring how to retain or rewrite primary SMTP addresses, and cutover custom domains. Make sure you check back to see the next installment.
This blog was guest written by Steve Goodman. Steve works at Content and Code as Principal Technology Strategist, spending half his time helping customers understand how best to utilize Office 365, and the other half of his time hands-on with some of the more complex problems associated with migrating to the cloud or to newer versions of Exchange Server. Outside of his day job, you’ll find Steve talking about Exchange, Teams, and Office 365 at user groups, conferences, on various blogs, and podcasts.