Hugh Roberts - 14.04.2020

So… You are in a Position where you must Move Office 365 Tenants

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


  • 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 centre, 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)


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.

  1. Geo-relocation or name change – usually simpler as the tenant is a Greenfield
  2. Merger or Acquisition – can be extremely complex, source and target may be in hybrid, domain migrations may need to occur & more
  3. 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




1. Name Change / Greenfield migration

  • Install second AD Connect instance to the target tenant
  • Do the cutover and domain removal/validation
  • Re-run hybrid wizard
  • Decom old AD Connect

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

  • Plan for cloud migration and soft matching later if possible
  • Be careful of people with active mailboxes in two places
  • If you can plan to change UPN’s and primary SMTP’s to the new domain, do this as part of the migration
  • Take into consideration domain migration requirements, if possible, do your email first
  • Take the time to set up the correct mail forwarding rules, connectors and groups and test them

Usually, these migrations need extremely careful planning to be completed successfully, we suggest engaging expertise

3. Divestment to Greenfield

  • Plan for forwarding after migration if required
  • Converting to mail-enabled users is usually easiest after migration
  • Consider a cloud-only approach to the migration
  • Audit shared data that needs to be transferred

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.


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.


The form was submitted successfully.

Join the Insentra Community with the Insentragram Newsletter

Hungry for more?

Who is Insentra?

Imagine a business which exists to help IT Partners & Vendors grow and thrive.

Insentra is a 100% channel business. This means we provide a range of Advisory, Professional and Managed IT services exclusively for and through our Partners.

Our #PartnerObsessed business model achieves powerful results for our Partners and their Clients with our crew’s deep expertise and specialised knowledge.

We love what we do and are driven by a relentless determination to deliver exceptional service excellence.

Insentra ISO 27001:2013 Certification

SYDNEY, WEDNESDAY 20TH APRIL 2022 – We are proud to announce that Insentra has achieved the  ISO 27001 Certification.