Exchange Online (Microsoft 365) to Exchange Online (Microsoft 365) - Migration Guide - Using Coexistence - Different Domain

This is the complete onboarding task flow for migrating mailboxes from one Microsoft 365 tenant to another Microsoft 365 tenant while using coexistence and not moving the source domain to the new destination tenant. A coexistence strategy is used when migration is planned to take many weeks or months with users being migrated in batches, and the users will need to continue to contact each other. This is also known as a 'Slow Burn' migration effort.

First time?

If this is your first time performing a migration, we have created a Migration Planning & Strategy Guide to walk you through planning, set-up, and general migration best practices. If you have never performed a migration before, we suggest reading that before beginning the steps outlined in this scenario.

There are several prerequisites and best practices for this type of migration. We strongly suggest that you review the Exchange Online (Microsoft 365) to Exchange Online (Microsoft 365) Mailbox Migration Guide before starting this migration. To learn more about any of the processes outlined in this article, visit the Microsoft 365 Mailbox Migration FAQ.


MigrationWiz is a migration tool, not a syncing tool. If changes are made at the source after migration, they will not sync to the destination, nor will changes made at the destination sync to the source. We do not have “live” monitoring of changes (as with a sync agent) and we cannot handle scenarios such as conflict resolution without user interaction.


It is important to highlight and meet the following prerequisites for a smooth migration project.


User Migration Bundle licenses are required for this migration.

Please refer to this document for details on how to purchase licenses and apply them to the mailboxes inside your project.


  • App password usage is not supported by this endpoint. 
  • Due to limitations on connections put in place by GoDaddy, we do not support migrating to or from GoDaddy using this specific migration type.  However, you can still migrate to or from GoDaddy using this guide instead: Exchange Online (Microsoft 365) to Exchange Online (Microsoft 365) Mailbox Migration Guide
  • Due to the types of calls made to the destination during coexistence migrations, IP Lockdown cannot be used with autodiscovery.
  • Only a single-target domain is supported.
  • We are not able to support migrations with two-factor or multifactor authentication. 
  • The maximum individual file size that MigrationWiz can support is 60GB.
  • Exchange Web Services (EWS) must be enabled for the mailboxes in the Exchange Online tenant for this migration type.

Product Update 

Azure Active Directory Connect (ADFS, AADConnect, and synchronization systems) is now a supported option in our Coexistence product. Please refer to the setup guides on Azure AD scenarios to see how best to set up and configure your migration.  

Configuring Modern Authentication to work with MigrationWiz and Exchange Online will be the default method by the end of December 2022 due to Microsoft discontinuing support for Basic Authentication in Exchange Online. The following Microsoft documentation outlines this change in more detail. Should you have additional questions on how this change may impact your tenant, please contact Microsoft to assist with providing that information: Deprecation of Basic authentication in Exchange Online

Updated Mailbox Permission Steps to Use in Place of the Application Impersonation Role

Starting in May 2024, Microsoft announced that they will begin blocking the assignment of the Application Impersonation role in Exchange Online and that in February 2025, they will completely remove this role and its feature set from Exchange Online, for more information click here.
If you do not already have an admin account with the Application Impersonation role assigned, use the steps outlined in the following KB to add the necessary API permissions (to use in place of the Application Impersonation role) to the Modern Authentication app you are using for your O365 mailbox or archive mailbox endpoint.

Migrated Items

Which items will migrate in this scenario?
  • Date/Time
  • Subject
  • Body
  • Importance
  • Sensitivity
  • Size
  • Item Class
  • Exceptions to recurring meetings
  • Inbox
  • Folders
  • Email
  • Contacts
  • Calendars
  • Tasks
  • Journals
  • Notes
  • Post (when the destination is Exchange or Office 365)
  • Server-Side mailbox rules
  • Client-side mailbox rules for Outlook
  • Automatic Replies (Out of Office Messages) 


    It is recommended to only migrate Automatic Replies in the last migration pass for the user. 
  • Personal Folder and Calendar Permissions

Resource Mailboxes

We handle resource mailboxes the same way that we handle regular user mailboxes. If you can log in to the resource mailbox using a web client (i.e., Outlook Web Access), we should be able to log in as well and migrate the data. If there is no way to log in to the resource mailbox using a web client (like OWA), then we also cannot log in and migrate the data.

In some cases, the resource mailbox is just a shared calendar owned by a user. In such cases, when the user's mailbox is migrated, we should be able to migrate the resource mailbox calendar as one of the user's calendars. Once the migration is complete, you could set sharing/permissions on the calendar so the users can access them.​​​

These items and settings will NOT migrate:
  • Safe Sender/Block Lists
  • Items that do not match folder types, i.e. calendar responses within a mail folder.


    If an item type is migrated into a folder of a different type at the destination, the item will not be visible.
  • Custom items that do not inherit from the core system types
  • InfoPath Forms
  • Calendar permissions (Exception for Exchange sources outlined below)
  • Calendar notifications
  • Calendar acceptance status emails
  • Modified description text & modified attendee lists for exceptions to recurring meetings
  • User-defined/custom fields for Contact items
  • Acceptance status for meeting participants
  • Personal distribution lists ("Contact groups" in Microsoft 365)
  • Server-based and dynamic distribution lists
  • Bounce notifications
  • RSS feeds
  • Mailbox sharing settings (aliases; delegates; client settings)
  • Mailbox rules and folder permission settings (these are only supported from Exchange Server 2010 SP1+ and later to Exchange Server 2010 SP1+ and later)
  • Personal Messaging Resource Management (MRM) Tags
  • Outlook Quick Steps
  • Client-side rule
  • Color-coding for categories
  • Pictures that have been added within a Business Card, under Contacts.
  • Calendar meeting links: Lync, Skype, or Teams events will be migrated but will usually not work in the destination because the links are for the source environment. These events will need to be recreated at the destination. There are exceptions to this rule, but they are not consistent.
  • Encrypted Emails: For all Source email systems, any email sent or received using encryption methods will not migrate using MigrationWiz. The emails will need to be decrypted before they can be migrated.

Prepare the Environments

The source and destination environments are set up the same way as a standard MigrationWiz project. Refer to this document - MigrationWiz Environment Preparation Guide - for information on what is required during this phase.

Modern Authentication Requirements

The steps listed in the Obtain Client and Tenant ID Settings for Mailbox and Exchange Online Migrations section of the Authentication Methods Migrations KB apply to both the source and destination tenant when they are Exchange Online, in regards to Exchange Web Services (EWS) in mailbox, archive mailbox, and public folder projects. Use a Global Administrator for the configuration steps.

Please review the documentation before preparing your environment.

MigrationWiz Steps

Create the Mailbox Migration project

You will now create the migration project.

Project Recommendations

Once a project is set up, you cannot add more users or make changes to the configuration by going back into the 'tenant-to-tenant migration options'. It is possible to keep adding more users by scoping them in the Azure AD groups as described below.

It is recommended that you create separate projects for differently scoped blocks of users. Although it is possible to keep re-discovering users in an existing project, think about creating a new project for each group of users to make things more manageable and to give more options to each set of users.

  1. Click the Go To My Projects button.
  2. Click the Create Project button.
  3. Create a Mailbox Project.


  4. Enter a Project name and select a Customer. If you have already created the customers, skip this section. If you have not already added the customer, click 'New' and add the details about the Customer here. This can be used in multiple projects so you only need to enter this information once.
  5. Click Next Step.
  6. Select the Microsoft 365 endpoint from the source endpoint dropdown menu. If you have already created your endpoints, you can select one here. If not, then selecting 'New' will allow you to create one.


  7. Select the Microsoft 365 endpoint from the destination endpoint dropdown menu. As you just did with the Source Endpoint, select a current one or create a new one if necessary.

    Client Secret for Microsoft 365 Endpoints

    For all Microsoft 365 Endpoints mailbox migrations (including archive migrations), MigrationWiz adds the Client Secret field, which is not always mandatory. It will depend on the permissions of the user account that performs the migration. Please review the following information before the creation of your M365 endpoints.

    • The client secret value is not mandatory if you use delegated permissions. Please leave the Client Secret field empty.

    • The client secret value is mandatory if you use the RBAC approach for application impersonation.

    • If you already have an admin account with the Impersonation role enabled (not using the RBAC approach) the client secret value is not mandatory. Please leave the Client Secret field empty.

Recommended Settings

The following KB outlines recommended settings depending on what scenario you are performing in your project: Recommended Settings for Exchange Online Microsoft 365 Tenant to Tenant Coexistence with Azure AD Connect

Configure Domain Addresses

The domain addresses serve as the suffix for the coexistence objects that are being created. When pointing forwarders from the target back to the source, the vanity domain signifies which one should be used. If the source is left blank, then it will use 'all' of the accepted domains in the source tenant as valid forwarder locations. By setting a single domain in this option, all forwarders will head to that single vanity domain.

The destination domain is a required field. The forwarders that are placed on the source during the full migration need to know which domain to use specifically.

Best Practice

It is normally best practice in migrations to have the UPN match the primary email address. This takes out any confusion when administering the migration. The alias that is applied to the ‘’ address is a solid and reliable method of forwarding as it is the anchor for the account in Microsoft 365.

Setting Global Administrator Credentials

The global administrator (GA) credentials are needed to connect to and configure all of the mail flow and object creations. They are also used in assigning licenses and performing pre/post-migration tasks. If GA privileges are too much for your local InfoSec to approve, then they can be scoped according to the mailboxes that are being migrated, both on the source and destination. The rights necessary inside Microsoft 365 and that of Exchange Administrator and the ability the perform License Operations. Therefore you can use 'Exchange Administrator' and 'User Administrator' on those scoped items.

Scope Mailbox Discovery

This optional field dictates what will be discovered automatically in the source tenant. By leaving it blank the system will detect ALL of the source mailboxes. It is recommended that you put a group name here and scope the mailbox discovery accordingly.

The best practice for this type of group is a 'Mail Enabled Security Group' which can be created inside the Exchange Admin Center on the Source Tenant, in the Groups section. Add the mailboxes into this group before you apply the group name to the options. It can have spaces etc. but must match the group name exactly.

An example of the Mail Enable Security Group in the EAC looks like this.


Wait time

The membership and construction of the group can take up to an hour, so we suggest having this set up and confirmed before the discovery process takes place.

Note that you can go back into this option at any time, change the group name, and rediscover the mailboxes. This will add those mailboxes to the project; it will not remove anybody who is no longer a member of the group. To do that, remove the project and rediscover all of the mailboxes.

Manage Distribution Lists and Groups

This is a separate scope from the Mailbox Scope that you have just defined. It gives you the ability to make a copy of items that exist in the Source Tenant, along with the associated memberships. So if you've scoped a project to a particular Mail Enabled Security Group and you select options in this dialog section, then those selected objects will be created on the target tenant regardless of the membership of the scoped group.

The optional lists/groups that can be brought across are the following

  • Distribution Lists
  • Mail-Enabled Security Groups
  • Security Groups
  • Dynamic Distribution Groups

These are migrated over during the project setup process and will not be removed on a rediscover process. Consider this option carefully as to whether you would like the system to create these objects on your behalf, or if you want a more manual approach to the creation.

Creation of Mail User Objects in the Target Tenant

There are two options in this section.

  • Create Mail User Objects in the Target Tenant
    The Mail User objects will be created in the target tenant to match the source objects. If an SMTP address is already in use in the target, then a numerical value will be applied to the address. The SMTP forwarding function is applied to the target object to send email to the source mailbox before the final cutover.
  • Do not create Mail User Objects
    With this option, no mail user objects will be created in the target tenant. This should be used when mailboxes are already provisioned for the incoming mailboxes in the target tenant.


The matching is performed on the SMTP address (left of @). When duplicate names are present these automated matches should be confirmed in the project view before starting a migration.

An additional item here is to decide if the system should match a corresponding item in the target tenant and go ahead and place the forwarder back to the source object. 

Convert Mail User objects during the Pre-Stage Process

As the Pre-Migration Process begins, this option will convert the Mail User object in the target tenant to a Mailbox User object. This will allow data to be migrated. Unselect this option if you will be performing this task manually before you start the Pre-Stage.

Apply Licenses to Target Mailboxes during the Pre-Stage Process

Here you can select if a license is applied during the Pre-Stage Process or not. Selection of the license type is based on an initial scan of your target tenant and the list shows the licenses available. Unselect this option if you wish to take care of the mailbox licensing separately.


Only specific Microsoft 365 licenses are supported for this migration. The supported types are listed in the Migration Setup drop-down menu. Only one Microsoft 365 license type can be used per project and the Microsoft 365 license types cannot be changed once the project has been set up.

Important Note

If you have this option deselected, or the convert mail user object option above, and start a pre-stage migration without a mailbox being present for the receiving data then the system will throw an error. This option is best used when there is a provisioning system in place on your configuration and you need the ability to perform this separately.

Post Migration Options

Finally, there is the matter of deciding how post-migration functions will work. Ordinarily, once the full migration has been completed, the forwarder is removed from the target tenant mailbox and placed in the source mailbox. This setting is the "Place Forwarder on Source Mailbox" radial that is selected by default when setting up your migration. However, if you would like the forwarder that existed during the migration process to continue forwarding mail from the target to the source, then select the "Leave Forwarder on Target Mailbox" radial.

Another option that can assist in a variety of migration scenarios is to rename the source mailbox with a 'MIGWIZ-' prefix. This will also add a Mail Contact record at the source for the original name. The user will have to log in to the new target tenant as they won't be able to use the source anymore. However, by renaming the source rather than deleting it, it can be recovered and reused if necessary. By having the contact record in place, the coexistence is preserved. See the screenshot below for the three post-migration options.


Starting the Discovery Process

Once you save the project and move forward, the system will perform its initial scan of the source environment. It will also perform the tasks that you specified concerning the creation of the objects in the Target environment. While this activity is occurring there will be a 'Processing' page displayed. Once the system is ready, this will jump to the main view of the project window that you would be used to in a MigrationWiz project. The discovery status will look like this.


The additional item that exists during a coexistence project is the notification on the right-hand side relating to what licenses are to be applied during the pre-migration processes if you have selected one.


Upon successful completion of the coexistence setup, you will see the migration project view with your list of discovered users (Example shown below).

Before submitting any pre-stage or full migration passes, now is the time to add the ClientID and TenantID support options to the Advanced Options of your project for your source and destination tenants. These options should have already been created by performing the required steps earlier in this guide under Modern Authentication Requirements. Steps for adding support options to a MigrationWiz project can be found outlined in the following KB under Support Option Setup: MigrationWiz Support Options.


Rediscover Items

At any time, you can click on the 'Rediscover Items' menu. This is very useful if additional mailboxes are added to your Azure AD scoping group. This will add mailboxes to the project and not affect what was already there.


Run a Pre-Stage Migration

Running a Pre-Stage Migration of a mailbox will start the following tasks depending on the options selected in the project setup.

  • If you have requested conversion of the Mail User contact, then MigrationWiz will convert that Mail User object to a User Mailbox, provisioning a mailbox in the backend of Microsoft 365 to accept data from the source migration during the migration process.
  • If you have requested a license to be applied, then the select license will be set on the User Mailbox. This will essentially allow this mailbox to be live and allow logins by that account. In essence, this will now be a live mailbox on the system.
  • The forwarder that existed on the Mail User object will still be in effect once the conversion to a true Mailbox is made.

Pre-Stage Note

If you have not requested that MigrationWiz perform these tasks then you will need to ensure that the Mailboxes are provisioned and licensed before starting the Pre-Migration step. Failure to do so will produce an error on that item.

Pre-Stage Migration Steps

To start the Pre-Stage Migration process, select the mailboxes that you wish to perform the task on, then;

  1. Click the Start button from the top.
  2. Select Pre-Stage Migration.
  3. Uncheck the box named Automatic Replies (This option will be removed from the Pre-Stage pass at a later date)
  4. Under the Migration Scheduling section, from the drop-down list, select 90 days ago.
  5. Click Start Migration.



The 90 days is a suggestion, you can select any option you prefer. The Pre-Stage migration will migrate only older items. This can be run multiple times with different timeframes selected to migrate data in smaller chunks.

In addition, at the bottom of the window, you can schedule the migration to start at a pre-set time.


Important Note

The migration process will start at the time specified, however, the pre-migration tasks are executed immediately. This means that any tasks around the creation of mailboxes, and assigning of licenses and forwarders from the target will take place straight away.

Full Migration

When the time arrives to cut over the batch of users, select the users and run a Full Migration. This sets up a mail forward on the source and, depending on the settings you chose during setup, either removes the forward from the destination mailbox or leaves the forwarder in place.

  1. Select the users.
  2. Click the Start button from the top.
  3. Select Full Migration.


    It is recommended to only migrate Automatic Replies in the last migration pass for the user.
  4. Click Start Migration. This migration will be completed fairly quickly since most data is migrated during the Pre-Stage migration; Microsoft 365 to Microsoft 365 migrations have high bandwidth available.

Note that you can schedule the migration for a pre-set time. If the process is being run without the pre-stage migration being performed first, then any items like the assigning of a mailbox license or forwarders, that are set in the project options will be executed immediately. It is the data migration that will hold until that particular time.



Error Reporting

If a pre-migration or full migration fails any of the tasks performed, there is now detailed logging in the migration line item view. Click on the email address of the migrating user in the console to view the specific error details. In the right-hand 'error' section, you will see a report that contains that information. An example is shown below.


In this example, the destination tenant had exceeded the number of available Microsoft 365 licenses are therefore produced this error.

After resolving the error, run the pre-stage again and it will continue from where it previously stopped.

MX Records

When all users have been migrated successfully, change over MX records on the DNS provider's portal. Make sure to include the Autodiscover (CName) setting.

Look through the user list and click any red "failed migration" errors. Review the information and act accordingly.

Rediscovery of items

If there are errors in a migration pass then the recommended initial fix is to run a rediscovery pass over the project. This will bring into line any changes with the source or target UPNs that are used and can often go a long way toward resolving these issues.

Rerunning the Premigration passes can also align these problems.

If problems persist, however, then please contact Support.


Was this article helpful?
0 out of 2 found this helpful