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

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.

Prerequisites

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

Licensing

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.

Limitations

Consider the following limitations for this type of migration.

• App password usage, MFA/2FA, and ADFS are not supported for the migration service accounts being used for this migration scenario.
• 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.

Migrated Items

Please click the bars below to check the migrated and non-migrated items. We are constantly working to create a better migration experience for you so these items may change over time.

Prepare the Environments

The source and destination environments are set up like 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 Required Permission for Performing M365 Mailbox and Archive Migrations article apply to both the source and destination tenant when they are Exchange Online, in regards to Exchange Web Services (EWS) in the mailbox, and archive mailbox. Use a Global Administrator for the configuration steps.

Please review the documentation before preparing the source.

Create an Administrator Account

Create an administrator account in Microsoft 365 to be used for migration or use the global admin account for the tenant. The administrator account must have full access to the user mailboxes, have the required API Permissions, or be granted impersonation rights.

We recommend adding the necessary API permissions to the Modern Authentication app you are using for your O365 mailbox or archive mailbox endpoint. You can follow the steps outlined in this guide, as this is BitTitan's recommended approach.

MigrationWiz Steps

Create the Mailbox Migration project

You will now create the migration project.

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 information can be used in multiple projects, so you only need to enter it once.
5. Click Next Step.
6. Select endpoints or follow the steps below to create new ones.
7. Click Next Step.
8. Configure the Project Settings.
9. Click Save Project.

Endpoints

Endpoints are created through MigrationWiz. If you select an existing endpoint from the dropdown, it will only show ten endpoints. If you have more than ten, you may need to search it.

Consider that endpoint search is case and character-specific. For example, Cust0mer will not show up if the search is customer. We recommend keeping a list of endpoints you have created, along with any unique spellings or capitalization you may have used.

Create your Endpoints

Please review the following tabs to create your destination and source endpoints.

Complete the Application (client) ID, Directory (tenant) ID, and Client Secret Fields

For Microsoft 365 Mailbox and Archive migrations, MigrationWiz adds the Application (client) ID, Directory (tenant) ID, and Client Secret fields.

While the Application (client) ID and the Directory (tenant) ID are mandatory, the Client Secret field is not. 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.

• Do not use the client secret value if you use delegated permissions (not the most recommended approach). When using delegated permissions, do not select the Use Impersonation to Authenticate checkbox in the source/destination tab of your project's advanced options.
• The client secret value is mandatory if you using the API Permissions approach.
• If you already have a migration service account with the Impersonation role enabled (not using the API Permissions approach) the client secret value is not mandatory. Please leave the Client Secret field empty.
  

  Warning

  Keep in mind that Microsoft has started removing the application impersonation role from O365, meaning there is no telling when that will eventually fail. It is highly recommended that you switch to the API Permissions approach.

For more information about how to get the Application (client) ID and Directory (tenant) ID values from the Application Registration, please review step 3 of this article.

Choose the Region of Destination Tenant

The Region of Destination Tenant feature optimizes migration performance and speed by identifying the region closest to the destination tenant (continent-level). For Microsoft 365 endpoints, MigrationWiz detects and selects the appropriate region automatically once you create and save your project.

Please note that each time you edit your project endpoints, the following message will appear at the top of your project window (where XXXX is the detected region):

Automatically detected destination tenant's region and assigned to the 'BitTitan Datacenter' in XXXX.

For this migration type, you cannot manually change the region of the destination tenant. In case you need to modify it, contact our support team.

Endpoint Validation

Once you finished configuring your project MigrationWiz performs an endpoint validation check. This validation tests the administrator credentials entered into the project and the Modern Authentication setup only. If there is an issue, the screen redirects to the endpoint and provides an error message or flyout that can be selected for more information regarding the error.

Common Errors when Configuring Your Endpoint

For more information on the AADSTS700016, AADSTS90002, and ADDSTS50126 issues review the Common Errors Using Modern Authentication page.

Project Settings

Once the endpoint configuration is complete, the Project Settings window will open. In this window, you can choose from the following options based on your requirements:

• Skip Modern Auth Credential Validation: By choosing this option you will disable the Modern Auth verification across all endpoints.
• Enable Tenant to Tenant Coexistence: By selecting this option, you can migrate end users while maintaining connectivity between domains as data is migrated.

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

In case you select the Enable Tenant to Tenant Coexistence option MigrationWiz will ask you to confirm and configure the following points considering your requirements and the information presented below:

• Configure Domain Addresses
• Setting Global Administrator Credentials
• Scope Mailbox Discovery
• Migrate Distribution List and Groups
• Creation of Mail User Objects
• Convert Mail User Objects during the Pre-Stage Process
• Apply Licenses to Target Mailboxes During the Pre-Stage Process
• Post Migration Options

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. All forwarders will head to that single vanity domain by setting a single domain in this option.

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

Setting Global Administrator Credentials

Global administrator (GA) credentials are needed to connect to and configure the mail flow and object creations. They are also used for assigning licenses and performing pre/post-migration tasks.

If granting Global Administrator (GA) privileges is too much for your local InfoSec team to approve, these privileges can be scoped to specific mailboxes designated for migration, both on the source and destination endpoints. The necessary rights within Microsoft 365 include Exchange Administrator permissions, as well as the ability to perform License Operations. Therefore, you can use the 'Exchange Administrator' and 'User Administrator' roles for 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. We recommend 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 to 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.

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.

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

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.

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.

Advanced Options

Configure or edit your project's advanced options by going to the Edit Project dropdown and selecting Advanced Options.

The following advanced options may be useful for your migration. 

Source/Destination Tab

For now, the new API Permissions approach does require the Use Impersonation to Authenticate box checked for your O365 endpoints along with the Client secret value that you supplied during the Endpoint creation.

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

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 for the project setup.

• Suppose you have requested conversion of the Mail User contact. In that case, 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 Migration Steps

Start the Pre-Stage Migration process by selecting 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.

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.
   

   Important

   It is recommended that only Automatic Replies be migrated 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, please contact Support.

Related Topics

• Retirement of RBAC Application Impersonation in Exchange Online
• Authentication Methods for Microsoft 365 (All Products) Migrations
  • Required Permissions for Performing M365 Mailbox and Archive Migrations 
  • Scoping Requirements for M365 Mailbox and Archive Migrations
• BitTitan - Data Security and Privacy Policy
• Recommended Settings for Exchange Online Microsoft 365 Tenant to Tenant Coexistence with Microsoft Entra Connect