In Part One of this series, we discussed the prerequisites for a migration. Such as, which apps can go, which can’t and what challenges you may be faced with. In this instalment, we’ll take a deeper dive into domains and identity creation and management, and velocity.
1. Domains
One of the bigger challenges in an Exchange Online migration (often correctly considered to be the easiest of the workloads to move) is maintaining a single domain across multiple tenants. This is a common issue in larger migrations when you need to migrate users across several days or potentially weeks.
If you’re not re-branding and continuing to use the same email domain, it’s impossible to host the same domain in two tenants, so how can we work around this?
A popular solution is to use a third-party Office 365 tenant to tenant migration solution to do address rewriting on inbound and outbound mail. In this scenario, you would typically use a sub-domain or alternate domain in the “target” tenant and rewrite outbound mail at the routing solution, so it appears to come from the original primary domain.
If you know this is going to be a temporary solution that can’t be worked around, another option would be to build and configure an Exchange Edge server, potentially in Azure, and route mail through the Edge server. You can read more information on how to do this here.
This would be preferable as you are normally tied into longer 1-3 year agreements with third-party providers, whereas you could decommission the Edge Server as soon as you were done. But you would need to weigh up the cost of licensing the server and Exchange against the other options.
In most scenarios, we see customers opting to increase migration velocity (more on this later) to reduce the impact and use a sub-domain, or similar, where there isn’t a third-party solution already in place. This means that any change in domain is only temporary for a short time, and no additional cost or complexity is introduced.
2. Identity Creation and Management
When speaking to customers about Office 365 migration plans, my key point to them is ‘Identity is everything’. This differs a lot from on-premises.
Identity is the entry point and control to everything within Office 365 and beyond. If you’re using Azure AD as your authentication provider for other enterprise applications, it’s critical you get the configuration of identity and ongoing management correct.
It can seem daunting at first, for example, you could have hundreds of users from separate directories that you need to work through to ensure there are not going to be any duplicate values. You must ensure you understand where the identities are going to be managed. Do you need to maintain an on-premises Active Directory, or are you going to remove AD completely and go with cloud-only identity management? You will often see when consolidating two different organisations new duplicate names that you didn’t have before, and you’ll need a strategy for identifying these and selecting which person gets the “non-standard” identity (i.e. John.Smith2@contoso.com).
Begin by determining where your “source of authority” lives. Typically, if this is an environment that already exists then the users here will become your “primary” accounts, and any duplicate values that arrive from the additional directory, will become secondary. Make sure you plan out how you will get any new identities into the new source, or if you even need to. For example, if you are currently running AAD Connect in two different AD forests to two different tenants, could you switch to using a single AAD Connect with multi-forest sync, or even use the new Azure AD Cloud Provisioning Agent?
There is a multitude of options, and there are not necessarily any right or wrong answers. The key is to ensure you have selected a strategy, planned out how you will implement it, and fully understand all the impacts of your chosen solution.
3. Velocity
The velocity of migration is always a difficult decision, regardless of what type of migration you’re executing. With tenant to tenant migrations, this can be particularly challenging as the native user experience isn’t as pleasant as Exchange Hybrid for example. And there are normally a lot more workloads involved due to the nature of moving across tenants.
At the highest level, your options are:
- Big Bang: migrating all your users in a single cutover, normally performed over a weekend. This is achieved by pre-syncing as much data as possible in advance, reducing the volume of data to be migrated at cutover. This approach reduces coexistence requirements and would answer the limitations for domains in a single tenant mentioned above. However, it will mean supporting all of your users in one day and would restrict your ability to pilot the migration and the additional risk created by moving so much data in one go which could impact whether everything is moved in time.
- Batched Approach: migrating users in batches is more controlled, and you can be adjusted to meet the business needs. You have less data to move at one time, and you have smaller numbers of users to support through the change. But you do incur additional complications in enabling coexistence for migrated and non-migrated users, the additional complexity in configuring mail flow across the two tenants, and the additional business cost to spreading the effort over a longer period.
As with a lot of these considerations, there is no right or wrong answer, and I have seen both options implemented successfully across several different clients. What you should ensure though, is that the approach is going to work for your project and your users, that you can meet the needs of the business, and de-risk the project as much as possible, whilst still ensuring success in a timely and cost-efficient manner.
In the final instalment of this tenant to tenant migration series, we’ll look at the last three considerations: ensuring you’re going to the right tenant, end user devices, and user communications and education.
