Hosted Exchange to On-Premises Exchange Migration Guide


This complete task flow is for migrating mailboxes from Hosted Exchange to On-Premises Microsoft Exchange, versions 2013, 2016, or 2019.

DeploymentPro currently can only officially be used with migration projects where Office 365 is the Destination. If using DeploymentPro with Exchange (either On-Premises or Hosted) as a Destination, then a Proof Of Concept should be run first. Exchange environments can have complex AutoDiscover settings, along with UPN and SMTP address mismatches, which can require troubleshooting and reconfiguration before DeploymentPro can be made to work against such environments. A Proof Of Concept will uncover any complications. 

This migration guide contains the necessary steps to perform the actual migration, but there are many steps to preparing for migration. 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.

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.

We are not able to support migrations with two-factor or multifactor authentication. 

Prepare the Source Environment

  1. Ask the Hosted Exchange Provider to create an account for migration purposes (e.g., named MigrationWiz) and grant full access rights to each mailbox by running this PowerShell script against the account called MigrationWiz:
    Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -User MigrationWiz
    • Some Hosted Exchange providers allow this access to be granted via their web portal. In this case, you could log in to each mailbox via their portal and then grant the migration account (e.g., MigrationWiz) to have read/write access to each mailbox. This is laborious and time-consuming, and so it is preferable that the Hosted Exchange provider run the PowerShell script above, particularly if you have a large number of users.
    • Some Hosted Exchange Providers will not grant this access. If that is the case, you can request credentials from your end users during the migration. Exact steps for this are provided under Option 2 in KB005086.
  2. If this is a very large project, the best results will be achieved by setting the project to use impersonation at the Source. In order to enable this, the PowerShell script below needs to be run by your Hosted Exchange provider. KB004727
    New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>Notes:
    • Many Hosted providers will not accommodate this request.
    • The second part of this process is to set your MigrationWiz project Advanced Options to use impersonation at the Source. This step is included in the MigrationWiz section of this guide.
  3. Test mailbox access. KB004616
  4. Export mailboxes to CSV file(s).
    • Ask the Hosted Exchange provider to provide them.
    • If the provider has an admin console which includes this capability, run their tool to export the user list (and, if necessary, the passwords) to the CSV file.
    • If you have admin credentials on the Hosted Exchange environment, you only need a list of the email addresses. You do not need the password for each mailbox being migrated, because MigrationWiz will use delegation and perform the migration based on the admin credentials.
    • If you do not have admin credentials on the Hosted Exchange environment (which is common), you must obtain all the email addresses and passwords for the users.
    • If the list of mailboxes and passwords from the Hosted Exchange provider is not available, request that the users send these to MigrationWiz as part of the migration process. See View, Add, and Edit Customers' Users for more information.


Prepare the Destination Environment

  1. Set up user accounts.
  2. Create an admin account for migration that has full access permissions to all mailboxes. KB004725
    • In the PowerShell script above, change the -User account to match the name of the admin account that was set up for migration.
    • Any user account that is a part of the domain administrator, schema administrator, or enterprise administrator groups will not have any administrative rights to mailboxes, no matter how many permissions are granted. A security default of Exchange Server is to explicitly deny any user that is a member of these groups. This is why we recommend creating a new user account specific for migration.
    1. Set up a remote PowerShell session with Exchange 2010+. KB005111
    2. To manually grant administrative access for migration, execute the following PowerShell command in the Exchange Powershell Console:
      Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -Automapping $false -User MigrationWizNotes:
  3. Disable throttling against the admin account. Refer to Option 1 in KB004945.
  4. Verify mailbox accessibility using EWS.​ KB004304
  5. If you want to be able to migrate messages with attachments larger than 10MB, the following limits need to be increased:
      • Increase message size limits. KB004613
      • Increase maximum accepted content length. KB004609
      • Increase maximum receive message size. KB004532
      • Increase maximum accepted request length. This is only valid if your Destination server is running Exchange 2007. KB004610

DeploymentPro Steps

  1. Launch DeploymentPro.
    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.
    1. Go to All Products > Device Management, 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 the customer DeploymentPro module:
  2. Activate DeploymentPro module for users.
    1. Either select all users or select individual users.
      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.
    2. Click the Schedule Cutover button.
  3. Schedule the profile cutover date.
    • Set the date and time for the Outlook profile configuration to occur, and click the Schedule Cutover button.
      • 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 the Mailbox Migration project. Read the How do I create a new migration project? article for more information.
  2. Add the accounts (also referred to as "items") that will be migrated to the project. Use the Bulk Add option, and then import from the CSV file that you prepared under the Prerequisites section of this guide. KB004842
    • If the list of mailboxes and passwords from the Hosted Exchange provider is not available, request that the users send these to MigrationWiz as part of the migration process. See View, Add, and Edit Customers' Users for more information.
  3. Set the Project Advanced Options. KB004834
    • If this is a very large project, the best results will be achieved by setting the project to use impersonation at Source (as documented in the Prepare Source Environment section of this guide). However, many Hosted providers will not accommodate this request. If they do, checkmark the box for Use impersonation at source.
      Note: Exchange impersonation (not delegation) utilizes per-user throttling quotas, which allows for a very large number of users to be migrated concurrently.
  4. Run Verify Credentials. KB004511
  5. Notify users that a migration is occurring. Send 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. KB004938
  7. MX Record Cutover. Change over MX records on the DNS provider's portal. Also, include the AutoDiscover (CName) setting.
    Note: If you are migrating in batches and mail coexistence is required, you will not be cutting over the MX records until your final batch of users has been migrated, and you must perform this extra step:
  8. Send email to end users to let them know what to expect for their Outlook profile reconfiguration. If using DeploymentPro, refer to KB005799 for some sample text and screen shots that can be included in this email.
  9. Enable Autodiscover again, so that users can create new profiles via Autodiscover, or use DeploymentPro to automate the configuration of new Outlook profiles. KB005363
  10. Full (Delta) pass: Select the users > Click the Start button from the top, select Full Migration > Click Start Migration. KB004938
  11. Run Retry Errors. KB004658
  12. Look through the user list and click any red "failed migration" errors. Review information and act accordingly.
  13. If problems persist, contact Support. KB004529
  14. 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.
  15. Click the pie chart icon in the MigrationWiz dashboard to receive an email containing all the project migration statistics. KB004626

Was this article helpful?
0 out of 0 found this helpful