How To: Step by step guide to a tenant to tenant migration with ODME and CPUU (4346104)

1.) Engage Microsoft Office 365 Support to create a Throttling policy in both the source and target tenants.

Note: Throttling policies usually have an automatic expiration date. This date should be noted. If the migration is not going to complete prior to the expiration of the throttling policy, then Microsoft should be re-engaged to extend the throttling policy before it expires.

2.) License users/create mailboxes in the new target Office 365 tenant. These users should use the default tenant UPN and email address (user@tenant.onmicrosoft.com).

3.) In the ODME Portal Connection Settings, setup the Source Connection:

System: Microsoft Office 365

Use auto-discovery should remain checked.

Provided an Admin User Name and Password

Note: The source admin account needs to have ApplicationImpersonation rights, see the following KB article:

How To: Grant Application Impersonation Rights in Office 365

4.) Test the source connection by entering in the primary email address of a user that will be migrated.

5.) In the ODME Portal Connection Settings, setup the Target Connection:

System: Microsoft Office 365

Use auto-discovery should remain checked.

Provided an Admin User Name and Password. (The target admin account should be using the default @tenant.onmicrosoft.com User Name.)

Note: The source admin account needs to have ApplicationImpersonation rights, see the following KB article:

How To: Grant Application Impersonation Rights in Office 365

6.) Test the target connection by entering in the default "user@tenant.onmicrosoft.com" address for a migrating user's target mailbox in the new tenant.

7.) In the ODME Portal Mailboxes list (step 2), use the primary SMTP address (user@domain.com) for all of the source mailbox addresses.

8.) In the ODME Portal Mailboxes list (step 2), use the default "user@tenant.onmicrosoft.com" address for all of the target mailbox addresses.

9.) Refer to the ODME Users Guide for information regarding Updating Outlook Client Profiles with CPUU:

ODME Users Guide: Updating Outlook Client Profiles

10.) Refer to the CPUU Users Guide for information regarding the configuration of CPUU and the source and target service accounts required to process Outlook profiles:

CPUU Admin Guide: Tenant to tenant migration scenario with domain name transfer

11.) CPUU service accounts, with mailboxes, will need to be created for both the source and target Office 365 tenants. These accounts should be created directly in the respective Office 365 portal. The UPN/Primary email address should be in the "cpuu@tenant.onmicrosoft.com" format. Additionally, these temporary CPUU service accounts can be normal "user mailbox" accounts without any additional rights.

12.) Additional steps can be taken to further limit the access rights granted to the source and target CPUU service accounts:

CPUU Admin Guide: How to Limit Account Rights

13.) Migrate mailboxes  with ODME:

a. In-Place Archives: Office 365 In-Place Archives can be migrated by selecting Source: Migrate from personal archives and Target: Migrate to personal archives on the ODME Options screen (step 3). The migration of In-Place archives will need to be performed as a completely separate migration pass. It may be best to turn off any source Office 365 archive policies before running the In-Place Archive migration, so that no new data is placed in the archive after this portion of the migration.

b. Older mail: Typically, the next step is to migrate normal Inbox data that is older than 90 days, or whatever time frame works best for the customer. This migration pass should only include "Email" data (not Contacts, Calendars Tasks, or Recoverable Items) and use a date filter to only migrate older data.

c. Final migration: The final migration pass should include "All Email", Contacts, Calendar, Tasks/Notes, and Recoverable items, as desired.

Additionally, the final migration pass should set "Enable Outlook Profile Update" and set "Forwarding" from source to target (entering the target "tenant.onmicrosoft.com" as the forwarding domain) to help minimize any delivery failures during the domain transfer process.

Note: There is no one "right way" to perform a migration. The suggestions above are merely a starting point for your migration plan. The migration plan should be customized to the requirements of the customer.

14.) Optional: If Azure AD Connect is being used to sync accounts from local AD to Office 365, then the sync engine should be stopped and/or migrating users should be taken out of the scope of the sync job. If you plan on using the same server for Azure AD Connect with the new tenant, then Azure AD Connect should typically be uninstalled at this time.

15.) Remove the primary domain from all source tenant accounts by going to Setup | Domains.

Note: Once this step is completed, mailboxes will no longer be able to be migrated using their current ODME license.

16.) Move the DNS MX records for the primary SMTP email domain to the new Office 365 tenant.

17.) Add the primary domain to the new Office 365 tenant.

18.) Optional: If Azure AD Connect is going to be used to sync the local AD accounts to the new Office 365 tenant, then it should be configured and syncing users to the new Office 365 tenant at this time. Typically, this requires a new install of Azure AD Connect.

Note: Typically, Azure AD Connect creates "soft matches" between local AD and Azure AD by using both the UserPrincipalName (UPN) and the primary SMTP address. Both of these values should match between the two directories before installing Azure AD Connect. The following Microsoft article provides more details:

Azure AD Connect: When you have an existent tenant

19.) Ensure that the primary email address for all users in the new Office 365 tenant is now set to the primary domain.

20.) Ensure that "Autodiscover" is working and pointing to the new target tenant by running the Microsoft Online Connectivity Analyzer.

21.) Configure Group Policy to run CPUU as a user login script from a network share.

Note: By default, CPUU generates log files from the profile update process in the same location that CPUU is launched from, therefore users should have write permissions to the network share for log files to be written.