In the era of cloud solutions, soon or later we will face the challenge of connecting two of them together. Merges and acquisitions of companies which possess separate cloud IT infrastructure needs to be joined, unified and also simplified if possible.

Using experience after few successful migrations, I will try to explain here the most important things to consider in similar projects, when Office356 is involved.

This is not step by step instruction – only lessons learned from the migration field.

At the beginning - things which appears every time you plan a change in the organization.

Determine customer expectations and goals

The most important thing, which – when chasing for time and money some people forget - the success of the project depends on the fulfilment of customer expectations. Dot.

Only accurately written and approved plan, accepted by both parties (client and contractor) have a chance to bring to a successful end result. Oversights, verbal, not written down or telephone agreements can cause unnecessary nerves, explanations, and in the worst case scenario, might be equal of additional costs, or even can prevent implementation of the project.

Merging companies – who is in charge here?

When companies decide to join forces they need to set common rules.

Very important security issues can vary greatly between organizations.

In the case of Office365 - some of the settings are made at the global level, so apply to all mailboxes, Sharepoint sites, OneDrives or Skype for Business, for example external sharing and the ability to contact Skype users outside the organization.

For such configuration it is required to establish a common policy, accepted by two companies.

Next thing – managing administrator roles in the Office 365.

At the moment it is not possible to control the scope of changes for a specific group of users, so that one IT department can manage for example one office only. Perhaps this will change over time. It is possible in the other hand to choose functional administrators for the whole tenant, i.e. who will be in charge for the users, who for global settings, and so on.

You can select: global, service, Sharepoint, Exchange, Skype for Business, billing, user management and password administrators.

Inform users before the start of scheduled work

Written information for employees about planned changes should be prepared ahead of time to communicate which part of everyday processes will be different from this point.

Every user needs to possess additional short guide describing how to behave in the new environment and what to do if something will not work as expected. This will reduce to minimum dissatisfaction of people and relieve IT department on the first day after the migration.

Tests, tests, tests

Because you can provision many Office 365 trial tenants, it’s easy to prepare test environment. Each phase of migration can and should be tested in practice, in order to make sure that everything will go smooth in production. You can also estimate time required for the execution of each step.

Office 365 migration – what to remember?

What do you need to remember when migrating between Office 365 tenants?

• Microsoft does not provide at the moment the possibility of transferring mailboxes, Sharepoint and OneDrive data in an automated manner between Office365 tenants

It is not possible to connect between the Office365 servers and send data from one to another. However, with the help of third-party tools like MigrationWiz from BitTitan, Quest Migration Manager from Dell, Sharegate-created especially for the Sharepoint and others - you can prepare and go through the migration process.

These pieces of software are of course paid tools, but they make O365 tenants migration projects possible.

• Both companies' environment-documentation

Planning, testing and selecting tools designed to migrate Office 365 data and the time needed for it, depends on IT environments of both companies.

Get answers to question about current IT environments in both companies (proposal of the list):

- if they work in one or multiple Active Directory forests,

- does AD migration or making trust are planned ahead of Office365 migration?

- have they additional mail servers - Exchange, Linux, relays, etc. ?

- whether the Exchange Server if in place, is running in hybrid mode,

- have they full access do their DNS zones of mail domains?

You should document all elements of mail flow, in order to be able to choose an optimal way to switch services.

• Configuration backup

Office365 has no backup option. It would seem that we will only copy data from source to the destination, so why to backup configuration?

Firstly, because after you disable synchronization with Active Directory you will lose access to your contacts and groups. If a new tenancy will connect with another AD, not having saved their parameters (names, redirects, permissions), means that you will need to recreate them manually.

On the subsequent stages of moving services you may find that one of such object blocks domain deletion and you will need to remove it. Backup configuration can prevent problems.

What I recommend to keep in safe place?

-list of Office 365 users (MSOLUsers),

-list of Exchange mailbox users,

-list of shared mailboxes,

-mailbox permissions,

-mailbox locale settings,

-mail forwarding,

-list and the parameters of the security and distribution groups,

-list of contacts and their parameters,

-Out Of Office (OOF) settings per mailbox,

-Exchange Online set (transport rules, DLP rules, spam filters, malware settings),

-other Office 365 settings-administrative roles, management roles and roles membership.

• Third-party tools can only copy the data, not syncing them!

You need to prepare customers that using third party tools to migrate Office365 between tenants, contents of mailboxes and Sharepoint/One Drive data are copied from one location to another. For example, if mail message has been copied to the destination mailbox and will be removed in source mailbox, then it will still exists in the destination.

These tools add security watermarks to objects in order not to duplicate items - once it has been transferred property, then it will not be migrated again.

• Licensing

To count the number of licenses in the Office 365, you have to remember that the shared mailboxes does not need it and license does not need to be assigned immediately, but within 30 days since the creation of the Exchange mailbox.

To determine migration tools license quota – you need to contact the seller.

• Cloud-based objects

When connecting two Office365 environments, you need to pay attention on objects of cloud type – created directly in the cloud environment.

In particular - when multiple administrators have access to the Office365 – it’s possible that there are many company non-standard entries created.

How to recognize objects created directly in the Office 365? You can check date of their synchronization with the AD. Cloud users, groups and contacts which have never been synchronized with the directory service, will have the lastdirsynctime parameter set to null ($null).

Powershell commands to check cloud identities:

get-msoluser-all | where {$ _. lastdirsynctime-eq $null}

get-msolgroup-all | where {$ _. lastdirsynctime-eq $null}

get-msolcontact-all | where {$ _. lastdirsynctime-eq $null}

• Office365Groups-cannot migrate!

A new type of object, which allows the users to create a group in Office 365.

Uses OneNote,Outlook and OneDrive. However, these are hidden objects that make up the whole of this specific "invention". Many administrators block the ability to create OfficeGroups due to lack of surveillance over them.

Command that is used for this purpose:

Set-OwaMailboxPolicy-Identity OwaMailboxPolicy-Default-GroupCreationEnabled $false

Due to its nature at the present time it is not possible to migrate Office365Groups.

If company actually started using them, you need to ask users to save all files connected with Office365 group and recreate it in the new environment.

To check for the existence of the Office365 Groups, issue a command:


After this command, we get a list of Office365 Groups or nothing - then this means that our tenancy does not have this type of groups.

• ADConnect-problems

When you change the configuration of the application used to synchronize data from Active Directory to Office 365 – the latest version of the app is called ADConnect (formerly Dirsync and later AADSync) – you can ancounter situation when even though changes were saved correctly – they simply don’t work - synchronization works only for part of the settings.

Short advice - After reinstalling and configuring everything again – it should work.

But there is also a second side of this process – if your company have big amount of changes to send over to the cloud - you need to arm yourself with the patience. Saving changes to the Office365 may take a long time (up to several hours). If you do not see ADConnect errors, you need to wait before the start troubleshooting process.

However, if you see errors in the console – react immediately – some of them stops synchronization process.

• ADConnect - multiple Active Directory forests

ADConnect allows you to synchronize multiple AD forests to one Office365 tenant.

Is assumed that the user accounts are unique-they do not appear in two different domains. However, when a user need to represented on two forests, you can select the parameter of which two objects will be identified.

There is also a GalSync supported scenario - contacts in one forest are combined during synchronization with the user objects in the other, so you can set permissions and access to the groups in two forests and one Office 365 tenancy.

• Domains federation

At the moment it is possible to federate multiple domains in one Office365 tenancy – users can authenticate through corporate ADFS servers to Office 365 using several domains (different UPN’s).

• Switching domain-downtime in the mail delivery

To move organization data from one Office365 tenancy to the other, one of the steps you need to perform is a domain migration. You cannot assign the same domain to two Office 365 tenants. You need to remove it from the existing one first, then add and verify in the second. This will be possible if you remove any domain aliases assigned to Office365 objects -mailboxes, groups, contact. This step is critical, because removing domain will stop mail flow directed to it.

If we do not use additional servers, which can take over the mail traffic for the duration of the switching domains (switching consists of removing, adding and verifying domain, changing MX records, waiting for DNS replication), for example hybrid on-premises Exchange Server, or Linux server – there will be a downtime in the mail service for selected domain.

You have to get this into account during planning stage and preparing migration steps for customer.

It is even more important when there are many, sometimes several hundred SMTP (mail) domains to migrate between the Office365 tenants, and at the same time you can get the verification code only up to 50 domains.

It is possible that you can also encounter unplanned obstacles, for example in the form of damaged objects – in my case it was when I cannot remove aliases and needed to remove object completely.

• OneDrive for Business (or OD4B)

In the Office365’s OneDrive each user gets their own, separate data space on Sharepoint Online server. At the time of writing this article it is 1 TB. Administrators problem is that by default, this is designed as a user private storage, so until changes of permissions they cannot access it and so migrate data. To copy it across the Office365 tenants, administrator permissions needs to be added to OneDrive sites. You can achieve this via Powershell script for all OneDrive sites.:

$Creds = Get-Credential

Connect-SPOService -Url -credential $Creds

$Users = Get-SPOUser -Site -limit all| Where-Object {$_.LoginName -like '*DOMAINNAME.DOMAIN*'}

$Users = $Users.LoginName | ForEach-Object { $_.TrimEnd("DOMAINNAME.DOMAIN") } | ForEach-Object { $_.TrimEnd("@") }

$Users | ForEach-Object {Set-SPOUser -Site"$_"_DOMAINNAME_DOMAIN/ -LoginName [email protected] -IsSiteCollectionAdmin $true}

or only for selected OneDrive’s if you prepare list beforehand (here it is named O4bUsers.csv)

$Creds = Get-Credential

Connect-SPOService -Url -credential $Creds

$Users = import-csv ./O4bUsers.csv

$Users | ForEach-Object { Set-SPOUser -Site $_.url -LoginName [email protected] -IsSiteCollectionAdmin $true }

The second issue related to OneDrive migration, is the fact that when you move its data to a new tenant, you need to prepopulate O4B sites first-they are not automatically created when you assign license to Office365 user.

Here comes Powershell again, however it is required to use complex script and prepare a list of accounts to be created beforehand.

You can get relevant information here:

During preparation of migration batches, be careful entering account parameters.

OneDrive and Sharepoint links will change accordingly to the domain connected to user UPN – that is when UPN (login name) changes, OneDrive url will change too – for example:

can change to:

Due to this process, you must set the correct source and destination addresses in the migration tools. Be aware and do not migrate data in the wrong way!

• SharePoint world

Although it is integrated with other Office365 services, it is a separate environment, which is governed by its own laws. It can have its own set of users, permissions, and services you need to keep in mind during the migration.

Microsoft has no out of the box solution to transfer data, configuration and structure between Office365 tenants, however, there are third-party tools which can help you with the migration.

The complexity of all of the Sharepoint features causing that there is no application that can mirror everyone environment in the new place. Every tool on the market has always some limitations. You need to check the documentation for a list of functions and properties that can be included in the migration and exceptions that just cannot be migrated.

Even though you choose the best tool, it is useful to have Sharepoint specialist on board on the planning phase, during and just after migration to help solving emerging problems.

• Contacts in the Outlook autocomplete file

Every time a user sends message to the new e-mail address, contact is saved in the list of suggestions in Outlook – autocomplete file. There would be nothing wrong with that, if not for the fact that within the organization this includes a reference to the server. Therefore, after migration, if the autocomplete file has been moved, you must remove migrated company entries from the list. In another case Non Delivery Reports will appear.

• Old entries with .onmicrosoft domain in calendars

After you successfully migrate mailboxes, you may find that some entries in calendars also refer to the old server-email addresses of people invite appear with domain. So far, I have seen this happens only for recurring meetings.

The only way to get rid of this annoying problem is to remove the problematic entries and recreate them again.

• Clutter - not important?

Another functionality of the new version of Exchange with is Clutter which is controversy. This feature tries to filter messages that should not be urgent or very important for the user. From experience I know that it is safer to disable this functionality, in order to avoid the frequent queries to check what happened with important emails.

Clutter removal for all mailboxes:

Get-Mailbox -resultsize unlimited |Set-Clutter -Enable: $false

• Mailboxes localization

In a multilingual company it is important to take language settings into account in the migration steps. When you move mailboxes from one Office365 tenant to another, you must also ensure that these parameters will be recreated.

Do not wait for the user first login and set them mailbox regional settings beforehand. Thing that can cause problems is the lack of localization of default folders (like Inbox, Sent Items) even though they seem to be applied correctly.

Way to solve this problem is to run this command (here with en-us language and yyyy-MM-dd date format settings):

Get-Mailbox-resultsize unlimited | Set-MailboxRegionalConfiguration-LocalizeDefaultFolderName: $true-language: en-us -DateFormat yyyy-MM-dd

• Immutableid

It is the AzureAD account parameter, an equivalent to the Active Directory ObjectGuid for mapping AD objects to AzureAD identities. This allows you to assign the account created earlier in the Office365, to their counterparts in the Active Directory and synchronize later.

• Removing synchronized accounts

You can still find blogs and other documents related to removing Active Directory synchronized accounts which advise to move an object to another organizational unit (OU) that is filtered with directory synchronization tool, to be able to remove it from Office365.

Now this is no longer necessary-you can delete accounts which already have immutableid parameter set. Such an account will be recreated after next synchronization (if it is still enabled on the AD side). If for some reason this is not working without it, you can use the parameter -force with Remove-MsolUser:

Remove-MSolUser-userprincipalname [email protected] -force


This article was written after successful finishing Office365 migrations to show you some things I believe important when planning such migrations. It does not give all answers about the subject, because each of the brief points can be expanded depending on IT environment. Office 365 service itself is in constant development and presented solutions may soon be replaced by others or outdated. auth = 1