This is the complete onboarding task flow for migrating mailboxes from one Office 365 tenant to another Office 365 tenant while using coexistence. This migration is usually 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 be able to seamlessly contact each other.
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 Office 365 to Office 365 Mailbox Migration Guide before starting this migration to ensure a successful migration. To learn more about any of the processes outlined in this article, visit the Office 365 FAQ.
All users on the source will be discovered to create mail-enabled contacts for those items on the destination. This migration type, therefore, is unsuitable for part divestitures from the source tenant. The mail-enabled contacts will be converted into cloud-only user mailboxes. Synchronization with on-premises objects with AADC cannot be performed until after the 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: Office 365 to Office 365 Mailbox Migration Guide
- Only a single-target domain is supported.
- We are not able to support migrations with two-factor or multifactor authentication.
- Item Class
- Exceptions to recurring meetings
- Server-Side Rules
- Folder Permissions
- Post (when the destination is Exchange or Office 365)
- Calendar acceptance status emails
- 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 Office 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 Source Environment
There are two ways to set up the proper administrator privileges: Global Admin, or impersonation.
Create a Global Administrator
Create a Global Administrator account in Office 365 to be used for migration or use the Global Administrator account for the tenant.
Create an Administrator Account
Create an administrator account in Office 365 to be used for migration or use the global admin account for the tenant. The administrator account must have either full access to the user mailboxes or be granted impersonation rights. We recommend using impersonation as it will help reduce the likelihood of the migration being throttled by Microsoft.
To manually set impersonation:
- Use admin credentials at the Destination.
- Sign in to the MigrationWiz account.
- Edit the Project and click on Advanced Options.
- If migrating from Office 365, under Source, check Use impersonation to authenticate.
- If migrating to Office 365, under Destination, check Use impersonation to authenticate.
- Click Save Options.
MigrationWiz will automatically run a remote PowerShell command to allow the admin account to log in to (impersonate) user mailboxes.
Test Administrator Access
Test that the administrator can access user mailboxes. Test access to the tenantname.onmicrosoft.com addresses, not to the domainname.com addresses. Make sure that the tenantname.onmicrosoft.com account is attached to each mailbox in Office 365. By default, it should be attached, but if not, it will need to be added as an alias to each account. This can be done through the Office 365 admin portal or via PowerShell scripts.
- Open the browser to https://portal.microsoftonline.com.
- When prompted for credentials, enter the user name and password of the account to be used to access the mailbox.
- This can be either the credentials of the end user mailbox itself or administrative credentials.
- To migrate using administrative credentials, enter administrative credentials into OWA.
- The result is a successful login to the Office 365 portal.
- Click on the Outlook link at the top right of the page. The Inbox should be visible.
- If using administrative credentials, change the URL so that it looks like the following example: https://email@example.com (replace firstname.lastname@example.org) with your information.
- Only change the portion of the URL after the OWA virtual directory by replacing it with the primary SMTP address of the mailbox.
- email@example.com is the primary SMTP address of the mailbox being accessed.
The Inbox of the mailbox firstname.lastname@example.org should be visible.
Optional - Export User List
Export a list of users from the source tenant. This will be used to import the users to be migrated into the migration project. You can find instructions to export a list of active users here: Microsoft 365 Reports in the Admin Center – Active Users.
The report can be exported as a CSV. You can then edit the CSV to add or remove users as needed.
Prepare the Destination Environment
Create a Global Administrator account in Office 365 to be used for migration or use impersonation, following the steps used in Prepare the Source Environment.
Prepare the tenant to send and receive large mail items
Important: The steps in this article require that you connect to Office 365 with Windows PowerShell. Refer to the Connect to Office 365 PowerShell article from Microsoft for detailed steps on how to connect to Office 365 using Windows PowerShell.
To migrate items to Office 365 that are larger than the EWS defaults, you will need to run the following PowerShell scripts.
First, you should run this script against your Office 365 environment to determine what your current settings are:
Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize
- The user can be any standard user on Office 365 that has an Office 365 license assigned that contains a mailbox license.
- It should be a user whose settings have not been previously modified.
MaxSendSize: 35 MB (36,700,160 bytes)
MaxReceiveSize: 36 MB (37,748,736 bytes)
Next, run this script against your Office 365 environment to set the Mailbox Plan, the Max Send Size and the Max Receive Size:
Get-MailboxPlan | Set-MailboxPlan -MaxSendSize 150MB -MaxReceiveSize 150MB
Note: New users created after you change the mailbox plan will have 150MB as the max send and receive size. However, the current user will still have 35MB. To increase the limit for all users you can run:
Get-Mailbox | Set-Mailbox -MaxReceiveSize 150MB -MaxSendSize 150MB
The example below shows how you can validate that the new limits are applied:
PS C:\Windows\system32> Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize
MaxSendSize: 150 MB (157,286,400 bytes)
MaxReceiveSize: 150 MB (157,286,400 bytes)
Create the Mailbox Migration project
You will now create the migration project and add your users.
Once a project is set up, you cannot add more users or make changes to the configuration except for advanced options. If you want to add users to the organization, please add them to the source before creating the project or add them manually to the destination. Once the project is created, users will be added to the project automatically from the source endpoint.
- Click the Go To My Projects button.
- Click the Create Project button.
- Create a Mailbox migration.
- Click Next Step.
- Enter a Project name and select a Customer. If you have already created the customers, skip to Step 6. If you have not already added the customer into MSPComplete, you will need to create them now.
- Log in to MSPComplete.
- In the left navigation pane, select the appropriate workgroup and then click All Customers.
- Click Add Customer.
- Enter the new customer’s information in the Add Customer form.
- Click Save.
- Repeat steps 1 through 4 for each customer you want to add.
- Click Next Step.
- Select the Office 365 endpoint from the source endpoint dropdown menu. If you have already created your endpoints, skip to Step 8. If you have not created your endpoint, follow these steps:
- Log in to MSPComplete.
- In the left navigation pane, select the appropriate workgroup and click All Customers.
- Click the customer for which you want to add an endpoint.
- Click the Endpoints tab at the top of the page, and then click Add Endpoint.
- In the New Endpoint form, provide the requested information under Details.
- Select the Office 365 endpoint from the destination endpoint dropdown menu. If you have not already added the endpoint to the customer in MSPComplete, you will need to follow the instructions in Step 7.
- If setting up a Tenant to Tenant Coexistence mailbox project, check the box for Enable Tenant to Tenant Coexistence. Otherwise, leave that box unchecked.
- Configure your Tenant to Tenant options.
- Configure Domain Addresses: Enter the primary Source and Destination vanity domain names. The Source domain is optional and can be left blank. This will enable coexistence for all domains on the Source.
- Setting Global Administrator Credentials: A Global Administrator account is required on both the Source and Destination endpoints.
Important: The destination tenant Administrator account needs to be able to access MSOnline, so the account must use the .onmicrosoft.com domain to ensure the correct access levels.
- Choose Office 365 License: Select the Office 365 License type to be used on the Destination. When the mail enabled contact is converted to a user account with a mailbox, this is the license that will be applied.
- Migrate Distribution List and Groups: Select the groups that are to be included as part of this migration. Changes to the Distribution Lists and Groups can be synced during the project.
- Click Save and Go to Summary.
During configuration of the project, up until a Verify Credentials or a Pre-Stage pass is run, the Office 365 licenses selection can be changed. Initially, the Office 365 license is selected for all users, after the users are added to the project, they can be selected and their individual Office 365 licenses edited.
MigrationWiz will automatically start to configure the Office 365 tenants for the project. This process may take up to 1 hour per 1000 users. MigrationWiz creates the users on the destination as mail-enabled contacts.
The migration project can be completed in batches, but all the users need to be in the same project. When ready to run a batch of users, select the users to be migrated in that batch.
Purchase and apply User Migration Bundle licenses for all the users being migrated. For this migration type, we suggest the User Migration Bundle.
- User Migration Bundle Licenses have unlimited data available per license.
- User Migration Bundle Licenses are applied to the customer's users and expire 12 months after their purchase date.
- Document, Personal Archive, and DeploymentPro projects are all included when using User Migration Bundle Licenses.
- This license type must be applied manually.
- Sign in to your BitTitan account.
- In the top navigation bar, click Purchase.
- Click the Select button and choose the license type you need.
- Enter the number of licenses you want to purchase. Click Buy Now.
- Enter a Billing address if applicable.
- Click Next.
- Review the Order Summary and enter a payment method.
- Click Place Your Order.
Applying User Migration Bundle Licenses
- Sign in to MigrationWiz at https://migrationwiz.bittitan.com.
- You can either sign in and make sure to select the MigrationWiz button above the email field or sign into MSPComplete page, then click the All Products button and select MigrationWiz.
- Select the correct workgroup on the top of the left navigation pane.
Note: This is the workgroup that the customer and migration project were created under. Your account must be part of the workgroup and project sharing must be enabled, if the project was not created under your account. For more information see Add and Edit Workgroups and Project Sharing in MigrationWiz.
- Click the project that requires licenses to be applied.
- Check the box to the left of the email for the user(s) to whom you want to apply a User Migration Bundle license.
- Click Apply Licenses then click Apply User Migration Bundle Licenses.
If you have more questions about licensing, including redeeming coupons, requesting refunds, or changing categories, see MigrationWiz Licenses.
Run a Pre-Stage Migration
This step converts the mail-enabled contact on the destination to a user account, applies the selected license to the user, and initiates the mailbox creation process. A mail forward is then set up from the destination to the source mailbox.
Mailbox creation can take up to 24 hours. Once the mailbox is available, the migration will proceed. If the migration has not started to move data after 24 hours, contact Support.
Once the Pre-Stage migration is run, the selected Office 365 license cannot be changed in the migration project.
Pre-Stage Migration Steps
- 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.
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 removes the forward from the destination mailbox.
- Select the users.
- Click the Start button from the top.
- Select Full Migration.
- Click Start Migration. This migration will complete quickly since most data is migrated during the Pre-Stage migration; Office 365 to Office 365 migrations have high bandwidth available.
When all users have been migrated successfully, change over MX records on the DNS provider's portal. Also, include the Autodiscover (CName) setting.
Look through the user list and click any red "failed migration" errors. Review information and act accordingly.
If any of the migrated users encountered errors during the migration, select them and run Retry Errors.
- Click the Go To My Projects button.
- Select the project that contains the users that you want to retry.
- Select the users that have migration errors.
- Click the Start button.
- Select Retry Errors from the menu.
- Click the Retry Errors button.
When errors are repaired, they will disappear from the error log. Some errors may not disappear if the Source item was not reprocessed (due to filters, for example), has been deleted or moved, or if the item failed again.
If problems persist, contact Support.
Click the bar chart icon in the MigrationWiz dashboard to receive an email containing all the project migration statistics.