This article explores the complexities associated with a specific type of Microsoft Office 365 tenant migration, as well as highlights a potential approach/architecture.

Problem Statement

How to successfully migrate users (employees and contractors) from one Microsoft Office 365 tenant to another (separate) Microsoft Office 365 tenant, covering the following capabilities and associated services:

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

On the surface, this sounds like a reasonably simple problem to solve, recognising the consistency between the source and destination (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.

Adding additional complexity, due to an Office 365 limitation, a single domain can only be associated with one Office 365 tenant at any one time. Therefore, if the domain (e.g. company.com) of the destination Office 365 tenant is already in-use within the source Office 365 tenant, it must be made available by removing all existing dependencies prior to any user migration.

In the context of an M&A activity, the destination domain would likely be a core part of the company brand (used across the entire value chain), therefore would need to be retained and remain operational throughout the migration period.

Finally, it is worth noting, any migration (regardless of the approach/architecture) would likely require administrative level access in both Office 365 tenants, as well as the associated Identity Access Management (e.g. Active Directory) services. This could have security, privacy and/or legal ramifications, especially when considered as part of an M&A activity.

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).

Requirements

Alongside the technical complexities associated with the migration, outlined below are a set of common business requirements, which must also be considered.

  1. The domain (company.com) must be retained and remain operational throughout the migration period.
  2. Allow for a phased migration.
  3. Ensure all inbound and outbound e-mail retains the original domain.
  4. Retained support for SMTP applications and Resource Mailboxes for the duration of the migration period.
  5. Retain access to the existing Office 365 tenant (specifically Skype, SharePoint) for the duration of the migration period.
  6. Any site that leverages Skype Enterprise Voice can retain access and maintain the original phone numbers for the duration of the migration period.

Due to the previously described Office 365 domain limitation, the first and second business requirements (domain retention and phased migration) create a conflict. This is because the required destination domain (company.com) can not be configured within the destination Office 365 tenant until the last user has been migrated. This “catch-22” limits the viable migration options, positioning a mass migration event (not desirable) or forcing some creative technical workarounds.

Approach/Architecture

Through an investigation of market providers who have experience managing Office 365 to Office 365 migrations, I would position 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, I have validated that the Power365 Platform could facilitate this type of migration, as well as enable coexistence (where required). As a result, the diagram below highlights a potential migration architecture.

Office 365 Tenant Migration

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

The data synchronisation itself would be relatively simple (although time-consuming). The real challenge relates to permissions, which would also need to be replicated, mapping each user (via a unique identifier) in the source and destination Office 365 tenants. This process would be 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 would leverage two domains, the source Office 365 tenant retains the original domain (company.com). The destination Office 365 tenant would be configured with a new domain (newcompany.com). This approach would mitigate 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 would be leveraged, which ensures all outbound email from the destination Office 365 tenant would be sent under the original domain (company.com). Additionally, any inbound email to the original domain (compnay.com) would be 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 would be achieved via federation between Skype for Business and/or Teams (source) and Teams (destination). This assumes Skype for Business would be fully replaced by Teams (as per the product direction from Microsoft). Therefore, regardless of the migration-state (pre/post-migration), users would still be able to interact via instant messaging, VoIP, etc.

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

Considerations

Although I have great confidence that this proposed approach/architecture would meet the business requirements, any migration and/or coexistence between two Office 365 tenants remains very immature. Therefore, I would anticipate issues, bugs and user confusion. For example, outlined below are a few considerations.

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

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

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

  • Internal Email: The previously described domain re-write service only impacts external email, therefore, any internal email sent from a migrated user would be under the temporary domain (newcompany.com). Considering this only impacts internal email, the brand impact should minimal.

Conclusion

There are multiple options that could be considered when attempting to migrate between two Office 365 tenants. Unfortunately, though my analysis, I have concluded that there is no “perfect” option, each having their own list of positives, negatives and risks.

As highlighted, the likely business requirement to support a phased migration results in a technically complex approach/architecture, requiring administrative level access to the source and destination (Office 365 and Active Directory), as well as introduces temporary middleware (adding cost).

With that said, I remain confident that the proposed approach/architecture would be viable and likely the only way to effectively manage and support the previously describes technical complexities and business requirements.

If you are planning or have experience migrating between two Office 365 tenants, I would be very interested to hear from you! I would also be happy to share my approach/architecture in more detail.

enterprise architecture enterprise_architecture ea microsoft office_365 o365 tenant_migration binarytree power365 sharegate innovation strategy lifeinwork