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 a migration is planned to take many weeks or months with users being migrated in batches, and the users will need to continue to seamlessly contact each other. This is also known as a 'Slow Burn' migration effort.

App password usage is not supported by this endpoint. 

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.

 

Configuring Modern Authentication to work with MigrationWiz and Exchange Online will be the default method by 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

Limitations

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

Prepare the Environments

The source and destination environments are setup 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

MigrationWiz Steps

Create the Mailbox Migration project

You will now create the migration project.

• Click the Go To My Projects button.
• Click the Create Project button.
• Create a Mailbox Project.

• 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.
• Click Next Step.
• 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.

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

The following screen will ask if you are setting up a Coexistence Project.

• *DO NOT* input any Tenant ID information in the 2 fields shown above under Tenant IDs - For use with Modern Authentication!
• Select the check box, after which you will be prompted to enter the word 'Confirm' as a confirmation that you are aware of the type of project you are creating.

 

The next screen outlines exactly how the entire project will function for coexistence. Each of the options is explained in more detail below.

• *DO NOT* input any Tenant ID information in the 2 fields shown above under Tenant IDs - For use with Modern Authentication!

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.

Setting Global Administrator Credentials

The global administrator (GA) credentials are needed to connect to and configure all of the mail flow and objects creations. They are also used in assigning licenses and performing the pre/post migration tasks. In the event that 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 into 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 that 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;

• 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 prior to 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.
Note: 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. Deselect this option if you will be performing this task manually before you start the Pre-Stage.

Apply Licenses to Target Mailboxes during 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. Deselect this option if you wish to take care of the mailbox licensing separately.

Note: 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.

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 on 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 login 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 it's initial scan of the source environment. It will also perform the tasks that you specified with regard to 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.

 

IMPORTANT: 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.

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.

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

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

• Click the Start button from the top.
• Select Pre-Stage Migration.
• Uncheck the box named Automatic Replies (This option will be removed from the Pre-Stage pass at a later date)
• Under the Migration Scheduling section, from the drop-down list, select 90 days ago.
• 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, 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.

• Select the users.
• Click the Start button from the top.
• Select Full Migration. IMPORTANT: It is recommended to only migrate Automatic Replies in the last migration pass for the user. 
• Click Start Migration. This migration will complete 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 setup 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. 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 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 UPN's that are used and can often go a long way towards resolving these issues.

Rerunning the Premigration passes can also align these problems.

If problems persist, however, then please contact Support.