Office 365 to Office 365 Migration Guide - While Keeping the Same Domain Name

Introduction

• This is the complete onboarding task flow for migrating mailboxes from one Office 365 tenant to another Office 365 tenant.
• Complete each step in the order listed. Links to corresponding Knowledge Base articles are provided.
• This guide is only valid if the domain name is staying the same at the Destination. If the domain name is changing, refer to the Office 365 to Office 365 Migration Guide - While Changing the Domain Name.
• The MSPComplete section includes the steps to deploy the Device Management Agent (DMA) to users. This is an Agent which includes modules for HealthCheck for Office 365 and DeploymentPro. Deploying DMA to end users is a prerequisite if you will be using HealthCheck for Office 365 and/or DeploymentPro. The steps for HealthCheck for Office 365 have been omitted from this guide because your end users are already using Office 365.
• DeploymentPro can be used to configure the Outlook mail profiles after the migration.
  Note: DeploymentPro is included with the User Migration Bundle license. DeploymentPro cannot be purchased as a standalone service license, and it cannot be added to the single-use mailbox migration license. If you wish to remotely configure Outlook mail profiles using DeploymentPro after a migration, purchase the User Migration Bundle license.
• MigrationWiz now supports the capability to share migration projects across a Workgroup. Migration projects are no longer tied to individual accounts, they are tied to Workgroups. When Workgroup Administrators turn on the Project Sharing feature, all Agents besides those who are Inactive are able to view all migrations projects.  For more information, visit Project Sharing in MigrationWiz.
• Office 365 to Office 365 migrations that are keeping the same domain name differ from the standard approach followed in other migration guides, because Microsoft only allows a domain to reside in one tenant at a time. For this reason, the following extra steps are included in this guide:
  • Adding a recipient mapping, under Advanced Options, to ensure that all email retains the ability to be replied to, post-migration.
  • Removing the domain from the Source tenant.
  • Verifying the domain on the Destination tenant.
  • The users should first be added to MSPComplete using the vanity domain name. An MSPComplete subscription can then be added to each user. However, before beginning the migration, the user addresses should be changed to use the .onmicrosoft.com domain names at both the Source and Destination, rather than the vanity domain names.
    Notes:
    • There will be some email downtime with this migration due to the time required to remove the domain on the Source tenant and add it on the Destination tenant. This is because Microsoft only allows the same domain to exist on one Office 365 tenant at a time. Exchange Online Protection (EOP) can't route email for the domain during the period of time when the domain is removed from the Source tenant and added to the Destination tenant, assuming the MX record is pointed at EOP. This results in senders getting a non-delivery report (NDR). Read the Move domains and settings from one EOP organization to another EOP organization TechNet article for options to queue email during this time.
    • Use of RecipientMapping is always recommended but is mandatory if you delete the domain before you start your Delta migration pass.

Prepare the Source Environment

1. Create an administrator account in Office 365 to be used for migration, or use the global admin account for the tenant. Read the How do I create an administrator account in Office 365, and then use this during migration? article for more information.
2. Test mailbox access.
   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.

Prepare the Destination Environment

1. Create an administrator account in Office 365 to be used for migration, or use the global admin account for the tenant. Read the How do I create an administrator account in Office 365, and then use this during migration? article for more information.
2. Set up accounts on Office 365 and assign licenses. These can be created in several ways:
   • Manually, one at a time. Read the Add users individually or in bulk to Office 365 article from Microsoft for more information.
   • By bulk import, via CSV file. Read the Add several users at the same time to Office 365 article from Microsoft for more information.
   • By PowerShell script. Read the Create user accounts with Office 365 PowerShell TechNet article for more information.
   • By DirSync, AAD Sync or AAD connect. Read the How do I synchronize my Azure Active Directory objects to Office 365? article for more information.
   • Using the BitTitan Sync Tool. Read the BitTitan Sync Program article for more information.
3. Test mailbox access.
   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.
4. Prepare the tenant to send and receive large mail items. Read the How do I migrate large mail items to Office 365? article for more information.

MSPComplete Steps

1. Create the customer. Read the View, Add, and Edit Your Customers article for more information.
2. Create the Source and Destination endpoints. Read the View, Add, and Edit Customer Endpoints
article for more information.
• For the Source endpoint:
  • Click Endpoints > Add Endpoint > Enter endpoint name > For endpoint type, select Office 365.
  • Click the Provide Credentials radio button, and enter the admin account credentials.
    Notes:
    • This should be a global admin account. If creating a separate admin account for the purpose of migration, refer to the Office 365 section in the How do I create an administrator account for login? article.
    • You should use the tenantname.onmicrosoft.com address, for the admin account domain name.
• For the Destination endpoint:
  • Click Endpoints > Add Endpoint > Enter endpoint name > For endpoint type, select Office 365.
  • Click the Provide Credentials radio button, and enter the admin account credentials.
    Notes:
    • This should be a global admin account. If you are creating a separate admin account for the purpose of migration, refer to the Office 365 section in the How do I create an administrator account for login? article.
    • You should use the tenantname.onmicrosoft.com address for the admin account domain name.
3. Add users to your MSPComplete customer. From your MSPComplete customer dashboard, click Users > Add Users > Add Users Through an Endpoint (Recommended).
4. Apply a User Migration Bundle license to each user. From the Users tab, select all the users that you wish to subscribe, click the Apply User Migration Bundle License button, and confirm. Read the Apply User Migration Bundle licenses to the Customer's Users article for more information.
5. Deploy DMA to users. Once DMA has been deployed to users, check the Users tab in MSPComplete. This will be populated with the user accounts that have DMA installed. DMA can be deployed by either of these options:
   • Via Group Policy Object (GPO).
     Note: This is the recommended methodology because no end user interaction is required. Read the How do I deploy the Device Management Agent with a Group Policy Object? article for more information.
   • Via email. Read the How do I deploy the Device Management Agent through email? article for more information.

DeploymentPro Steps

1. Launch DeploymentPro.
   1. Go to All Products > Device Management, then click on DeploymentPro on the far left and follow the prompts to launch.
   2. Select a customer from the list by clicking on the customer name.
      Note: The status column will show Enabled when a customer account has had DMA deployed to users.
   3. Configure customer DeploymentPro module:
      1. Enter the Domain.
      2. Select the Destination endpoint.
      3. Checkmark the Auto-populate box.
      4. In the Client Interface Configurations section, upload your company logo and add supporting text.
         Note: We strongly recommend doing this, because this is the logo and text that end users will see in a desktop pop-up when they are prompted to reconfigure their Outlook profiles. If you do not upload your own logo, the default BitTitan logo will be included instead.
      5. Save and continue.
2. Activate DeploymentPro module for users.
   • Either select all users (by putting a checkmark in the box to the left of the Primary Email column heading) or select the individual users (by putting a checkmark in the boxes to the left of the user email addresses).
     Note: DeploymentPro is included with the User Migration Bundle license. DeploymentPro cannot be purchased as a standalone service license, and it cannot be added to the single-use mailbox migration license. If you wish to remotely configure Outlook mail profiles using DeploymentPro after a migration, purchase the User Migration Bundle license.
   • Click the Schedule Cutover button.
3. Schedule profile cutover date.
   • Set the date and time for the Outlook profile configuration to occur, and click the Schedule Cutover button.
     Notes:
     • The DeploymentPro module will install on user devices immediately and then run silently until this date.
     • The profile cutover date should be set to a date and time that is shortly after MX record cutover.
4. On the profile cutover date, users will be guided through the reconfiguration of their Outlook profile.

MigrationWiz Steps

1. Create a Mailbox Migration project. Read the How do I create a new migration project? article for more information.
   • Create the Mailbox Migration project > Select the customer > Select the Source endpoint > Select the Destination endpoint.
2. Add the accounts (also referred to as "items") that will be migrated to the project. Read the How do I add items to my migration project? article for more information.
   Important:
   • Select Add > Add from MSPComplete.
     Note: This will import the MSPComplete subscribed users into your MigrationWiz project.
   • Change the domain names for each user at both the Source and Destination to the tenantname.onmicrosoft.com.
     • To bulk change the Source addresses to the tenantname.onmicrosoft.com, follow the directions in How do I bulk change the domain name in migration email addresses? article.
       Note: This will be used for migration rather than the vanity name. This is important because, after the Pre-Stage migration pass, the vanity domain name from the Source must be removed. There will still be a Full (Delta) migration pass after domain removal, which is the reason for using the tenantname.onmicrosoft.com domain name.
     • To bulk change the Destination addresses to the tenantname.onmicrosoft.com, follow the directions in the How do I bulk change the domain name in migration email addresses? article.
       Notes:
       • This is the only domain name that initially exists on the Destination tenant, so it must be used during migration.
       • You can manually change source and/or destination addresses on a one by one basis, by clicking on the pencil icon on the right-hand side of the line item that you want to edit, and then changing the address in the email address field for either source or destination.
3. Set the Project Advanced Options. Read the What project Advanced Options are available? 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. Read the How do I migrate to Exchange or Office 365 using impersonation? article for more information.
     • Set to use impersonation at the Destination. Checkmark the Use impersonation at Destination box. Read the How do I migrate to Exchange or Office 365 using impersonation? article for more information.
     • If this is a large migration project, the value for maximum concurrent migrations​, under Advanced Options, should be set to a maximum value of 25 concurrent migrations, in order to gauge the tenant migration capabilities. If successful, this value may be increased incrementally.
     • Under Support/Support Options, add the following: RecipientMapping="@sourcetenantname.onmicrosoft.com->@destinationdomainname.com" Read the How do I add Recipient Mappings to a project? 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.
       • More than one remapping 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).
4. Run Verify Credentials. Read the How do I verify credentials? article for more information.
5. Notify users that a migration is occurring. Send an email to all users telling them the time and date of the migration.
6. Pre-Stage 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. Read the How do I start a migration? article for more information.
7. Remove Domain from Source.
   Note: 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
     Notes:
     • 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.
       Note: 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.
8. Send an email to the users to let them know what to expect for their Outlook profile reconfiguration. If using DeploymentPro, refer to the Sample email to send to users before their Outlook profile is reconfigured article for some sample text and screenshots that can be included in this email.
9. 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.
10. 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 tab. This page lists the DNS records necessary to set in order to use the Office 365 services.
11. 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. Read the How do I start a migration? article for more information.
12. Run Retry Errors. Read the How do I retry failed items? article for more information.
13. Look through the user list and click any red "failed migration" errors. Review the information and act accordingly.
14. If problems persist, contact Support. Read the How do I get support for your products? article for more information.
15. If not using DeploymentPro, users must create new Outlook profiles, and set up their signatures again, and reattach any PST files that were attached to their previous profile.
16. Click the pie 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.