Office 365 to Office 365 Mailbox Migration Guide

Follow the steps below to prepare for your migration. Once you have completed these steps, you are ready to begin your migration.

To discover what items are moved with MigrationWiz in this scenario, and which items will not be moved, see Moved Items. Note that these items will vary by source and destination, so check the proper environment listings carefully.

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.

Note: This guide does not include steps for when using Coexistence during the migration. For the migration strategy guide when using Coexistence, see Office 365 to Office 365 Migration Strategy: While Changing the Domain Name and Using Coexistence.

 

Introduction

Complete each step in the order listed. Links to corresponding Knowledge Base articles may be provided for additional context. These will automatically open in a separate window.

Links to the other guides may be included to provide FAQs, resources, and introductory guides for products relevant to this strategy.

We recommend completing this migration with multiple migration passes as instructed in the MigrationWiz steps, as this will cause the least impact on the users.

MigrationWiz is not a sync tool. Already migrated items updated at the source mid-migration will not be updated at the destination.

MigrationWiz supports the capability to share migration projects across a Workgroup. When the Project Sharing feature is turned on, all active agents can view all migration projects.

 

Prepare the Source

  1. 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. For specific steps to set impersonation manually, see Delegation and Impersonation.
  2. Test that the administrator can access user mailboxes.
    Note: 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. Read the How do I test mailbox access? article for more information.
  3. (Optional) 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.
    Note: The report can be exported as a CSV. You can then edit the CSV to add or remove users as needed.

 

Prepare the Destination

  1. Set up user accounts on the destination Office 365 tenant and assign licenses. These can be created in several ways. We have a few options listed below:
  2. 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. For specific steps to set impersonation manually, see Impersonation & Delegation.
  3. Test that the administrator can access user mailboxes.
    Note: 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. Read the How do I test mailbox access? article for more information.

 

MigrationWiz Steps

  1. Create a Mailbox Migration project.
  2. Add the user accounts that will be migrated to the project. Read the How do I add items to my migration project? article for more information.
    • For small migrations, it is easy to add users one-at-a-time using Quick Add.
    • For larger migrations, we recommend either using the Autodiscover or Bulk Add options.
      • Autodiscover will add all users found on the source tenant. This can then be edited in the project to remove users not being migrated. All users will be added with the source and destination email addresses set to match the source email. This can be changed by using the Change Domain Name button at the top of the project page. If the usernames are changing during the migration, we recommend using the Bulk Add option.
      • Bulk Add uses a CSV containing the source and destination email addresses for the users to add the users to the project. If migrating only a specific group from a tenant, we recommend using the Bulk Add option.

Important: If the domain name is being migrated to the new destination tenant, it is strongly recommended that users in the migration project be migrated using the OnMicrosoft domain names for both the source and destination email addresses, rather than using the vanity domain.

To do this, you'll add the user's using their Vanity Domain and once they're in the project, select all the users and click the Change Domains option in the menu to bulk change them to using the OnMicrosoft domain. Read How do I bulk change the domain name in migration email addresses? for more information.

This process is especially important if you'll be migrating the user's OneDrive data in a Document project as the vanity domain is used there.

  1. Set the Project Advanced Options. Read the MigrationWiz - Advanced Options & Options article for more information.
    • The following options are most valuable for this migration scenario:
      • Set to use impersonation at the Source. Checkmark the Use impersonation at Source box.
      • Set to use impersonation at the Destination. Checkmark the Use impersonation at Destination box.
      • Under Support/Support Options: RecipientMapping="@sourcetenantname.onmicrosoft.com->@destinationdomainname.com" Read the Recipient Mappings section under Advanced Options for more information.
        Notes:
        • The RecipientMapping above is just an example; do not copy this verbatim. It needs to be changed to reflect the sourcetenantname.onmicrosoft.com account name and the customer destination domain name.
        • If the domain name is changing, then the source vanity domain can be used in the RecipientMapping as in this example: RecipientMapping="@sourcedomainname->@destinationdomainname"
        • More than one mapping expression can be used.
        • This is a very important step for Office 365 to Office 365 migrations. It ensures that emails have the ability to be replied to, even after the Full (Delta) migration has occurred because they will be mapped to the new destination domain name, rather than using the old sourcetenantname.onmicrosoft.com account name (- which will no longer be available, once the tenant is retired).
  2. Run Verify Credentials. Read the How do I verify credentials? article for more information.
  3. Purchase appropriate licenses, see MigrationWiz: Licensing for more information.
  4. Run a Pre-Stage migration pass: Select the users > Click the Start button from the top and 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 mail items. This can be run multiple times with different timeframes selected to migrate data in smaller chunks.
  5. Remove Domain from Source.
    Notes:
    • This should only be done after the Pre-Stage migration pass has completed. Typically, it is done late on a Friday night. If you need instructions for removing a domain, refer to this document from Microsoft: Remove a domain from Office 365
    • If there are several domains in the Source tenant being moved to the new tenant, all of them need to be removed.
    • In the admin portal, change the UPN of the admin account to the onmicrosoft.com address.
    • After domain removal, users will not be able to access their email, unless they know and log in with their tenantname.onmicrosoft.com email addresses.
    • After removal, wait 30 minutes for domain removal replication to complete.
  6. Send an email to the users to let them know what to expect for their Outlook profile reconfiguration. If using DeploymentPro, you can use the DeploymentPro Guide now to set up the users on the destination for Outlook profile configuration.
  7. Verify Domain at Destination. These actions are performed from within the Tenant 2 (Destination) admin portal.
    • Verify the domain in the Destination Office 365 account. We recommend the use of the wizard in Office 365 for this since once the domain is verified with the Text record, it offers to change all the users to the new Default Domain.
      Note: Since the domain was previously added to the account, all that needs to be done is to click the Verify button. If the domain is unable to be verified, and there is an error saying the domain already exists on another account, contact Microsoft Support at 1-866-291-7726 (US Toll-Free, other numbers are also available), and tell them that the domain needs to be manually deprovisioned from Forefront.
    • Confirm that every user has the Destinationdomain.com domain name added to their mailbox. Add if necessary.
    • The step above should have added the domain to every user. Download the add_new_domain.ps1 PowerShell script to check for this and add the domain name. This is only necessary if the users do not have the new default domain added to their account.
  8. MX Record Cutover. On the DNS provider's portal, change the primary MX record to reflect the DNS settings for the new Office 365 organization. DNS settings to change include Autodiscover, MX, and SPF records. Also, remove the old settings for Tenant 1. These settings can be found in the Office 365 admin portal, by following these steps:
    • Inside Office 365, click Admin in the header.
    • On the Admin page, click Domains in the left pane.
    • Click the domain name to be set up, and then click the DNS Settings This page lists the DNS records necessary to set in order to use the Office 365 services.
  9. Full (Delta) pass: 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.
  10. Look through the user list and click any red "failed migration" errors. Review the information and act accordingly.
  11. Run Retry Errors. Read the How do I retry failed items? article for more information.
  12. If problems persist, contact Support. Read the How do I get support for your products? article for more information.
  13. If not using DeploymentPro, users must create new Outlook profiles, set up their signatures again, and reattach any PST files that were attached to their previous profile.
  14. Click the bar chart icon in the MigrationWiz dashboard to receive an email containing all the project migration statistics. Read the How do I request statistics for my migration project? article for more information.
Was this article helpful?
2 out of 2 found this helpful