This is the complete onboarding task flow for migrating mailboxes from one Microsoft 365 tenant to another Microsoft 365 tenant while using coexistence. 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.
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.
Azure Active Directory Connect (ADFS, AADConnect, and synchronization systems) are now a supported option in our Coexistence product. Please refer to the setup guides pertaining to Azure AD scenarios to see how best to setup and configure your migration.
- 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.
- Basic Authentication must be enabled in the Office 365 tenants for this project type at this time. Steps for requesting Basic Authentication to be enabled in an O365 tenant can be found outlined by Microsoft here: Basic Authentication Deprecation in Exchange Online – September 2022 Update
- 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
- Item Class
- Exceptions to recurring meetings
- Server-Side Rules
- Folder Permissions
- Post (when the destination is Exchange or Office 365)
- Calendar acceptance status emails
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 that is owned by a user. For those 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 that it can be accessed by other users.
- Safe Sender/Block Lists
- Items that do not match folder types, i.e. calendar responses within a mail folder. Important: 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
- 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 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.
Create the Mailbox Migration project
You will now create the migration project.
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 into 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.
- 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.
- 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.
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.
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 ‘onmicrosoft.com’ 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 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.
The membership and construction of group can take up to an hour, so we suggest having this set up and confirmed prior to the discovery process taking 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 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.
If you have this option deselected, or the convert mail user object option above, and start a pre-stage migration without a mail box 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 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.
Upon completion you will see the migration project view, so you can start your migration processes. 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.
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.
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 your options selected in the project setup;
- If you have requested a 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.
If you have not requested that MigrationWiz perform these tasks then you will need to ensure that the Mailboxes are provisioned and licensed prior to 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;
- Click the Start button from the top.
- Select Pre-Stage Migration.
- 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.
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.
- 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.
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.
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.