Howard M Cohen

Compelling Content Creator/

No date
Published on:
2 min read


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


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



1120 112TH AVENUE NE, SUITE 300


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


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


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

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


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


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 “†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


Instead, all accounts from the Source tenant will first be converted to their domain name. So “†would be converted to

“†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 “†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


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


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


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


• 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


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!