In some cases, companies have a need to move cloud-based mailboxes to the on-premises environment

We recently took on a project that involved migrating mailboxes from Office 365 to on-premise. This post describes the experiences we had migrating 10,000+ mailboxes from Office 365 to the on-premises organization in a Hybrid scenario, along with tips to know along the way.

man holding envelope icon

Gathering Mailbox Data

Before proceeding, we ran a number of PowerShell scripts to get all the necessary information to clearly define the migration tasks and responsibilities. This included mailbox sizes, mailboxes on hold, and resource mailboxes. Many were initially created in Office 365.

These resources were then created in a non-syncing OU, e-mail enabled, and configured to match primary SMTP addresses for the resources.  Once complete, we converted them to standard mailboxes and moved them to a syncing OU for SMTP matching.  Finally, through remote mailbox move commands, we migrated users back to the on-premises Exchange environment.

Tracking migration status

Tracking the migration status is no small task. We wrote scripts that granted us the ability to track the migration status in real-time and import data to an Excel project. Many large organizations use a plethora of security groups. It proved necessary to rely upon PowerShell to identify and update permissions on the fly again overcoming deltas between AD, on-premises and the 365 environment. Finally, we worked with the client to identify the appropriate DB target capable of handling the additional workload. We migrated to 95%, and completed them in batches, and based on a closely monitored project plan we scheduled the final de-provisioning of the account from the 365 tenant.

Errors when migrating Office 365 to the on-premises environment

Finally, throughout the project, we encountered one-off users that did not have an email address matching the smart host name and/or the user’s mailboxes had significant corruption.

We located this article and applied the fixes provided. It helped because there are always a few mailboxes that need extra attention. Luckily it was a small percentage that required a manual approach. We utilized Exchange Migrator by MessageOps to export the PST once that was completed. We obtained a copy of the users Proxy addresses, disabled the mail user, and enabled the user as a mailbox on-premises. Once the user’s mailbox was enabled on-premises, we added the proxy addresses that were missing. Upon completion, we removed the cloud object to clear out the mailbox on Office 365 and granted a user full access to that mailbox and imported the PST through a rich client.

Access needed for migration

  • A user on-premises that is a member of the company’s management team
  • A user that is an Office 365 Global Administrator
  • A user that is a member of Enterprise Administrators

Things to know for a successful migration

  • Mailbox sizes on Office 365
  • Disk space on-premises – verify that you have enough space to house the mailbox
  • Resource mailboxes on Office 365 are not always DIRSYNC objects
  • Mailboxes on hold – determine the best method to help a client maintain compliance
  • Users missing proxy address – alias matching the smart host was used for the Hybrid Configuration
  • Corrupted mailboxes
  • Users that have linked mailboxes – before you migrate the users remove the linked mailboxes
  • Users that are a member of certain security groups that are used to manage Office 365 users
Was this article helpful?