This article is part of a series (links below). I would recommend reading the articles in order, starting with “Greenfield Opportunity”, which provides the required framing.

The previous articles have focused on technology, positioning and delivery. This article will highlight a specific problem statement related to Microsoft Office 365.

Problem Statement

Due to our unique situation, we have the requirement to migrate 8000+ users (employees and contractors) from one Office 365 tenant to another (separate) Office 365 tenant, covering the following capabilities (and associated services):

  • Individual Mailbox
  • Individual Calendaring
  • Individual Files (OneDrive, Box, Local Drives)
  • Individual Unified Collaborations (SharePoint, Teams)
  • Individual Unified Communications (Skype, Teams, Cisco)
  • Shared Mailbox
  • SharePoint Sites (SharePoint 2010, SharePoint Online)
  • PowerApps

On the surface, this sounds like a reasonably simple process, recognising that in the majority of cases, the source and destination are the same (same provider, same architecture, same technology). Unfortunately, this is where the challenge begins…

Microsoft prioritise new Office 365 customers, therefore have comprehensive playbooks and FastTrack services (including automation) to migrate users from legacy and competing services (e.g. Exchange On-Premise, Lotus Notes, Google Apps, etc.)

Unfortunately, migrating users from Office 365 to Office 365 is less common (usually driven by an M&A activity), as well as less commercially lucrative for Microsoft. Therefore, although Microsoft offers consultancy, they do not have any formal playbooks and consider this type of migration “out of scope” for their FastTrack services.

To add an additional layer of complexity, the planned domain ( of our destination Office 365 tenant is already in-use within the source Office 365 tenant. This domain is a core part of the company brand (used across the entire value chain), therefore must remain operational throughout the entire migration period.

Unfortunately, due to an Office 365 limitation, a single domain can only be associated with one Office 365 tenant at any one time. Therefore, before the domain can be transferred to a new Office 365 tenant, it must first be made available by removing all existing dependencies.

Finally, any migration (regardless of the approach) requires administrative level access in both Office 365 tenants, as well as the associated Identity Access Management (e.g. Active Directory) services. This can have security, privacy and legal ramifications during an M&A activity, further complicating the migration.

As a result, migrating from Office 365 to Office 365 is arguably the most complex migration path and the least mature (limited support, resources and available expertise).


Alongside the complexity of the migration, we also have specific business requirements. For example:

  • Allow for a phased migration.
  • Ensure all inbound and outbound e-mail retains the original domain.
  • Retained support for SMTP applications and Resource Mailboxes for the duration of the migration period.
  • Retain access to the existing Office 365 tenant (specifically Skype, SharePoint) for the duration of the migration period.
  • Any site that leverages Skype Enterprise Voice can retain access and maintain the original phone numbers for the duration of the migration period.
  • The Office 365 tenant migration can (if required) be decoupled from all other migration activities (network cutovers, laptop replacements, etc.)

Due to the Office 365 domain limitation, the first business requirement (phased migration) is the most complex. This is because we cannot configure the required domain ( within the destination Office 365 tenant until the last users have been migrated. This “catch-22” limits the viable options, forcing a mass migration event (not viable) or a creative technical workaround.


We began the planning process in May 2019, resulting in an investigation of the market providers who have experience managing Office 365 to Office 365 migrations. Through a close partnership with World Wide Technology (WWT), we evaluated a number of technical solutions, eventually positioning Binary Tree.

Leveraging the Power365 Platform, Binary Tree state:

“With a cloud-based software platform, Binary Tree makes it easy to unify and move users between two or more Office 365 tenants to support mergers or long-term multi-tenant coexistence.”

The word “easy” is definitely relative, however, through a comprehensive proof of concept, we validated that the Power365 Platform could help facilitate the migration, as well as enable coexistence. The diagram below highlights our migration architecture.

Office 365 Tenant Migration

The Power365 Platform and ShareGate are used to migrate and synchronise all email, calendars, address books and content between the two Office 365 tenants (and other source locations). This is achieved by pre-positioning data ahead of the user migrations, followed by a delta synchronisation to ensure the latest state is available.

The data synchronisation itself is relatively simple (although time-consuming). The real challenge relates to permissions, which must also be replicated, mapping each user (via a unique identifier) in the source and destination Office 365 tenants. This process is prone to error, but assuming the “owner” of the data (file/folder/group) is accurate, retrospectively reassigning the correct permissions should be a trivial task.

As highlighted in the diagram, the architecture leverages two domains, the source Office 365 tenant retains the original domain ( The destination Office 365 tenant is configured with a new domain ( This approach mitigates the Office 365 domain limitation, however, has ramifications for any user operating within the destination Office 365 tenant.

To ensure a seamless experience for all users and the recipients of any email, a re-write service is leveraged, which ensures all outbound email from the destination Office 365 tenant is sent as the original domain ( Additionally, any inbound email to the original domain ( is automatically forwarded to the destination Office 365 tenant. Therefore, the migration should be transparent to all users and the recipients of any emails, protecting the brand and ensuring business continuity.

Collaboration is achieved via federation between Skype for Business (source) and Teams (destination). Therefore, regardless of the migration-state (pre/post-migration), users can still interact via instant messaging, VoIP, etc.

Finally, once the last user has been migrated, the domain in the source Office 365 tenant can be released and transferred to the destination Office 365 tenant.


All of our due-diligence has given us great confidence that the proposed architecture will meet our requirements. However, as previously stated, migration and coexistence between two Office 365 tenants is still immature, therefore we anticipate issues/bugs. For example, outlined below are a few considerations we have identified.

  • Global Address List (GAL): Ideally, the Global Address List (GAL) in the source and destination Office 365 tenants must be updated and synchronised ahead of any user migrations. If this is not complete, users will be forced to manually look-up and input email addresses.

  • Personal Assistants: Although the architecture we have defined enables a phased migration, there are still fixed dependencies between specific user groups. For example, if a personal assistant is migrated separately from their team, they will temporarily lose access to any delegated email, calendaring, etc.

  • Orphaned Meetings: Due to the nature in which data is copied between Office 365 tenants, certain historical re-occurring meetings may become orphaned (no ability to update). In this scenario, if the meeting needs to be modified, it would need to be recreated. The impact of this consideration should naturally reduce over time.


Through our evaluation with World Wide Technology (WWT), we identified multiple options to migrate between two Office 365 tenants. Unfortunately, we concluded that there is no “perfect” option, each having their own list of positives, negatives and risks.

Driven by our desire to enable a phased migration, our chosen architecture is technically complex, requiring administrative level access to the source and destination (Office 365 and Active Directory), as well as introducing temporary middleware (adding cost).

The proof of concept, where we conducted over 3000 tests, was a critical part of the process, helping us validate that the architecture was viable and could scale, especially considering the complexity of the source Office 365 and Active Directory architecture.

At this time, we remain confident that the architecture if fit for purpose, however, remain very aware that we will likely encounter unforeseen issues/bugs during the production migration (testing every usage pattern would be almost impossible).

Our production migration is set to begin in February 2020 and (assuming everything goes to plan) will run until December 2020.

If you are planning or have experience migrating between two Office 365 tenants, we would be very interested to hear from you! I would also be happy to share our architecture in more detail, as well as our experience as we scale throughout 2020.