WHITE PAPER

Planning Guide for Office 365 Tenant Migrations

Introduction
Over the past decade, migration projects have largely been from on-premises systems and applications into
the cloud, beginning with email and later expanding to include documents and file shares. Cloud office
productivity suites, namely Office 365 and G Suite, have and continue to drive this transition. Gartner expects
that by 2021, 70% of businesses will be significantly provisioned with cloud office capabilities. As the late
majority coverts to Office 365 and the market continues to become more saturated, the frequency of
migrations from cloud office to cloud office, dubbed “tenant to tenant” or “T2T” in the case of Office 365,
is only set to increase.

The need to migrate between Office 365 tenants is often driven by a significant business event: a merger or
acquisition, divestiture, or larger internal reorganization effort. While many steps to migrate users and data
between tenants remain the same as traditional on-prem to cloud migrations, there are considerations
unique to T2T projects that need to be planned and accounted for.

The purpose of this guide is to provide migration project owners and business stakeholders with a
list of early considerations once the need for an Office 365 tenant migration project is established.
For more technical planning resources and step-by-step migration guides, see the Additional Resources
section at the end of this document or visit the BitTitan Help Center.

Understand Your Current Environment

“Measure twice, cut once.” The old carpenter’s rule is applicable when it comes to any migration. Before you
move any data, be sure you know and understand exactly what you have in your current state Source
environment. To plan for a successful project, your team will need to have a comprehensive picture of:
• All users complete with settings and rights
• Mailbox specifications for each
• All groups that have been established and which users are in each
• All applications that are in use, which users and groups are using each, and which are due for
updating
• All data entities, where they are stored, what they are used for by which applications, how
frequently they are accessed, and how large they are
• How each data entity is backed up and where

Envision Your Future Environment

Based on your Source environment and specific business needs, begin to imagine what your Destination
environment will look like. Migrations naturally open the door for larger IT and application changes.
 WWW.BITTITAN.COM

Whether that be using a new tool or application in the Office suite, adjusting governance policies to better
serve and protect your workforce, or simply transitioning away from old processes, take the time in the pre-
migration phase to outline how the organization and its data, applications, and processes will work on the
Destination.

Identify what can remain behind, too. Not all of an organization’s data needs to be migrated. Certain
departments such as finance, legal, and human resources may need to maintain long-term records for the
sake of compliance; however, the average employee likely doesn’t need access to email from three years
ago.

Older assets that are seldom accessed should be migrated to near-line destinations such as archives. Finally,
assets older than a specific date, or which are almost never used, can be moved to completely offline media.
Be sure to include this assessment in your comprehensive inventory.

Using this opportunity to “clean house” is another effective way to reduce risk during the migration and
overall data transfer times. Oversized mailboxes and complex, heavy file trees are often the source of errors
during the physical migration – tidying up Source environments and large mailboxes will save you time,
energy, and headaches once the project is underway.

Determine Whether You’re Keeping or Changing The Domain Name

Most every company has its own domain name that it uses for its website, email accounts, and other internet
activity. As an example, BitTitan’s domain name is bittitan.com.

When two or more companies merge, one of the decisions that will be made at a board and executive level
is which of the two companies’ domain names will be used for the new entity. In some cases, the acquired
company continues to run under its own name for a considerable length of time, in which case there will be
no need to migrate anyone or anything. Both Office 365 tenants will continue to operate independently as
well.

In other cases, it is decided that the combined companies will operate under a completely new brand and
name. In this case, neither of the existing domain names will be used. The migration process is significantly
impacted by which of these scenarios will be the case.

Tenant to Tenant – Keeping the Same Domain Name

Every Office 365 tenant has its own identity in the onmicrosoft.com domain. Office 365 allows for a
“vanity” domain name to be assigned, namely your own domain name such as “bittitan.com”. Both
the Source and Destination Office 365 tenants will likely have vanity domain names assigned to
them.

One might think that the tenant-to-tenant migration is simplest when keeping one of the domain
names. Just change the vanity domain name for the other “@tenant.onmicrosoft.com” to be the
same as the one that is being kept. However, Office 365 allows a specific vanity domain name to
only be assigned to one tenant, so this cannot be done.

1120 112TH AVENUE NE, SUITE 300 2

BELLEVUE, WA 98004
 WWW.BITTITAN.COM

Instead, all accounts from the Source tenant will first be converted to their
@tenant.onmicrosoft.com domain name. So “[email protected]” would be converted to
“@[email protected].” A process called “recipient mapping” is performed to assure
that all migrated email can still be replied to once the migration is complete. Other tools, such as
BitTitan’s DeploymentPro, will be used to assure that all the accounts on the new tenant are
configured properly and stay configured properly.

The user accounts from the Source tenant will be added to the Destination tenant and their email
addresses changed from “onmicrosoft.com” to the Destination vanity domain name.

At cutover, the vanity domain name from the Source tenant will be removed and the vanity domain
name on the Destination tenant will be verified.

Tenant to Tenant – Changing the Domain Name

The most important difference when all users are being migrated to a new domain name occurs at
cutover.

Domain Name Service (DNS) is responsible for maintaining a directory of which domain names
correspond to which actual internet protocol (IP) addresses. Whenever a new domain is added or
changed, or a record such as the MX record is changed, DNS must notify its global network of the
changes. It takes time for new information to be propagated to all DNS servers, sometimes
considerable time.

Since this introduces a new mail exchange service under a new domain, DNS begins its notification
service during which it may not be possible to exchange mail with other servers. This process should
be scheduled during non-working hours and all users notified of possible delays. This is one of
those few times when you will have no control over downtime. Plan accordingly.

Select Your Solution

With pre-migration assessments complete and strategy identified, it’s time to begin evaluating solutions to
help you execute this project. First-party solutions from Microsoft provide support some parts of this
transition, as do other third-party solutions on the market. Here are elements to keep top of mind as you
evaluate these tools:

Setup and Configuration

How long will it take my team to set up and configure our migration project? Do I need to take the
extra step to install something in my Source environment, or is it 100% SaaS? Is my team able to
set this up without any certifications, training, or additional professional services?

Data transfer speeds and testing

Based on number of users and amount of data, how long can I expect this migration to take? Can I
test with made up users before kicking off the actual project and make sure all my scripts work?

1120 112TH AVENUE NE, SUITE 300 3

BELLEVUE, WA 98004
 WWW.BITTITAN.COM

Security concerns
Do you store any of my end user’s data? What sort of infrastructure does your organization use to
support my migration? Is my data encrypted while in-transit?
Support at scale
Does your solution scale to meet the demands of a large-scale, long-term project? If applicable, do
you offer coexistence between two tenants? Can I use PowerShell SDK to help customize and script
part of this process?

In order for a tenant migration to be successful, your team needs to feel confident and knowledgeable
about the solution used to perform the actual data transfer. Include education around your chosen solution
as part of the pre-migration plan for IT.

Also important is understanding support options available through the vendor if you do choose a third-
party solution. The worst-case scenario is that something breaks during the migration and your team
doesn’t have access to or can’t reach support resources to troubleshoot. Read up on support options and
invest strategically if you feel additional support is required.

Involve End Users in Planning

A 2018 survey sponsored by BitTitan and conducted by Osterman Research found that MSPs felt the most
difficult part of a migration was supporting and educating users themselves. If limiting downtime and
disruption to end users is a priority during this transition, a defined communications plan outlining what
they need to know or actions to take is critical to project success.

1120 112TH AVENUE NE, SUITE 300 4

BELLEVUE, WA 98004
 WWW.BITTITAN.COM

Partner Technical Strategists at BitTitan advise a “T-minus” communication plan that works back from when
users will actually be migrated. This steady stream of information from migration project owners or internal
IT to end users helps prepare them for the transition and can expedite work that needs to happen on the
Source ahead of the move. Consider not all users may be moved at the same time and therefore
communication strategies should be staged with the appropriate batches.

Here’s an example of those notifications:

• 30-45 days out: Outline what users need to know or steps to take on their local machines to
ensure a smooth transition. Handle one-off actions that have arisen from your pre-migration
assessments.
• 14 days out: Follow up with those who still need to complete any steps before the move. Set
expectations about any planned downtime or interruption to user email systems.
• Three days out: Provide more granular details about when users will or will not have access. Alert
users to any post-migration actions they will need to take to get settled in the Destination.

Also be sure during your pre-migration tests to observe what the end user experience will look like during
the migration. Consider what messages or alerts look like on mobile devices or their desktops. Anticipate
questions and proactively fix issues that arise from these tests to ensure the real cutover is seamless.

1120 112TH AVENUE NE, SUITE 300 5

BELLEVUE, WA 98004
 WWW.BITTITAN.COM

Additional Resources
This document was designed to provide guidance during the early planning stages of a tenant migration.
Here are links to additional resources concerning T2T migration projects and MigrationWiz, including
technical migration guides, demos, and on-demand webinars.

• Migration Guide: Office 365 Tenant Migration – Changing Domain Name

• Migration Guide: Office 365 Tenant Migration – Keeping the Same Domain Name
• On-Demand Webinar: The Guide for Office 365 Tenant to Tenant Migrations
• Demo: Office 365 Tenant Migration – Keeping the Same Domain Name
• Webpage: About BitTitan’s Office 365 Tenant Migration Offering
• On-Demand Webinar: Top Tips for Office 365 Tenant Migrations with Coexistence

Still have questions regarding Office 365 tenant migrations and MigrationWiz? Contact us today!

1120 112TH AVENUE NE, SUITE 300 6

BELLEVUE, WA 98004