Now – I use the word must in the title because nobody wants to do this. Why? I hear you ask, well, Tenant to Tenant (T2T) migrations are generally complex and messy, especially when looking at more than just mailboxes. Luckily for you, we have completed this several times and we are here to help.
Below are some of our learnings from the field broken down into three parts:
- High-level recommendations
- Scenario recommendations
- Gotchas
HIGH-LEVEL RECOMMENDATIONS
- Identity is king – we need to ensure the identity strategy being leveraged for each migration is planned out, including considerations for things other than the tenant migration itself. Considerations like domain migrations, integrated authentication and provisioning should all be taken into account when planning the migration
- Improve as you go – nothing is stopping you from changing or implementing something different in the target, we frequently find it’s easier to implement governance or features during this sort of migration, but be careful of biting off more than you can chew
- Migrate in a “big bang” cutover if you can – anyone who tells you co-existence is the best option isn’t telling you everything. If you must do co-existence for a particularly critical business unit or operations center, do it for as short a time as possible (we usually recommend 1 week). This doesn’t mean we can’t validate data or the experience for users, we can and do
- Consider making life easy for yourself by impacting users a little bit. Sounds like a strange one, but trust me, bending over backwards to get this done without user impact is extremely difficult, costly and will usually end up impacting users anyhow. An example of this is blocking the use of OneDrive for as long a period as the business can handle, we recommend 24-48 hours before cutover to save headaches on final sync
- Don’t worry about migrating everything, place important data into retention policies and retain the old tenant for compliance reasons until your retention period is up (assuming your compliance and discovery requirements enable you to do this)
SCENARIO RECOMMENDATIONS
To bring some focus, let me summarise three of the most common scenarios we see for T2T, together with some notes and comments on each one.
- Geo-relocation or name change – usually simpler as the tenant is a Greenfield
- Merger or Acquisition – can be extremely complex, source and target may be in hybrid, domain migrations may need to occur & more
- Divestment – Usually less complex as the target tenant is greenfield however there are lots of considerations for the source concerning what data to separate and migrate to the new environment, as well as the underlying identity and infrastructure in the target
The above are general statements – all scenarios are different and require careful planning to ensure the specific scenario requirements are being met
| Scenario | Notes | Comments |
| 1. Name Change / Greenfield migration |
| The easiest method, AD Connect will take care of all the attributes. There is no need to set up any additional rules for mail flow |
| 2. Merger or Acquisition |
| Usually, these migrations need extremely careful planning to be completed successfully, we suggest engaging expertise |
| 3. Divestment to Greenfield |
| While sometimes simpler than an acquisition due to identity usually being a straight forward split, careful planning around the data separation and migration, selecting correct objects to migrate and ensuring mail flow still works for old email addresses must be undertaken. |
GOTCHAS
To this end, we have developed a list of considerations for T2T
- Careful Planning – I can’t stress this enough, with a single migration window comes the need to plan every detail
- Change Management – There are a lot of things which need to be communicated during a T2T, here are the main ones we go through, but depending on the circumstances there may be more:
- Calendar appointments will need to be rebooked as they are no longer linked with anyone else
- profiles will need to be resynchronised to the local device
- Teams or Skype for Business integrated meetings will need to be rescheduled
- External sharing for files doesn’t move across
- Favourites and links will likely be broken
- Spam filter settings are reset
- Signatures, Mailbox rules, and mailbox layout will need to be re-established (unless using a tool to assist with this)
- Mobile devices will need to be reconfigured
- There WILL be downtime, especially for Outlook and Mobile Devices while Autodiscover redirects
- OWA is the quickest to get working
- Any PC’s joined to Azure AD will need to be re-joined at cutover
- More!
- Azure subscriptions will need to be migrated – note there is no easy migration option for different geo’s
- Consider what else is in use in the tenant, PowerBI, Flow, Forms, LogicApps, PowerApps, Teams and Office 365 Groups, all need careful planning and consideration
- Outlook caches will need to be resynched – this may impact the network but can be mitigated by policies or change management
- Enterprise Applications will need to be re-registered
- SharePoint customisations can be difficult to migrate and require careful planning
- Consider directing MX records to a non-existent address for the cutover until you get your new MX from the new tenant after domain verification – this will mean sending servers can’t establish a connection and therefore will queue this mail which is a better experience than sending and failing, unless of course, you have a third party service that can “pause” your email, which also works!
Tenant to Tenant migrations are invariably complex pieces of work which require careful planning and risk management. If you are planning one and wish to get some assistance, let us know.
