Recently I had the challenge to move the Exchange Online (Office 365) mailboxes of a small business back to an on-premises Exchange 2013 server. In this article, I'll outline the steps I took and the obstacles I encountered in this cloud to on-prem migration.

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

This small business had no on-premises infrastructure, just a Windows server hosted in a public cloud running Active Directory and file services along with a few line-of-business (LOB) applications. And all of their collaboration was through Office 365.

The heavy mail user profile ^

Veterans in the Exchange server space will remember the challenges in sizing servers, where you could fit 500 "light" mail users on a server, or 100 "heavy" users. And of course, users don't fit in predefined boxes nor do they change their habits, making sizing difficult at the best of times.

After an initial outline by the client's IT department, it seemed like moving these few users should be a fairly easy process. After all, how difficult could it be with only a handful of users? When I met with the actual users and started investigating how they use Exchange and Outlook, I realized that it would be a bit more challenging. This business is a recruitment agency, linking job seekers with open positions. They rely on a third-party Outlook add-in (Fasttrack) that links applications to jobs in the database behind the scenes. The first challenge was to make sure this add-in continued to work after the migration.

The second challenge was the size of the mailboxes; with generous limits in Office 365, they had accumulated quite a horde of emails from the last 10 years. After a clean-up and archiving to shared PST files of the really old stuff, the largest mailbox was still 12 GB with the rest around 8 GB—not huge but still a factor for download speeds.

The third challenge was that they were also going to add two new email domains, along with needing to point their existing domain from Office 365 to the on-premises server. The business relies on an external spam-filtering service from Symantec. Thus, I had to add the new email domains to DNS and the spam-filtering solution.

The fourth issue was that they didn't just have individual mailboxes; they also had several ordinary user mailboxes that they were sharing amongst several users. In addition, they had a large collection of signatures they picked from manually when sending out emails, depending on which address they were sending from.

Their requirements were also specific. I couldn't just assign multiple email addresses to a single user mailbox because the users had to be able to pick which email address to send a new email from. And they could only do that using separate mailboxes. (I found an application that does allow this from a single mailbox: ChooseFrom/SmartReply, but the cost and risk of running third-party software on the Exchange infrastructure was too high.)

The plan ^

Planning is vital, especially for a business that's very reliant on email. The plan was:

  • Set up user mailboxes on the on-premises Exchange server for each user.
  • Set up shared mailboxes for all individual users in the two additional email domains so they pick "send from" when creating a new email, thus making sure any replies end up in the right inbox.
  • Do the migration over a weekend and create forwarding rules from the Office 365 mailboxes to the Exchange server so that no email is lost.
  • Download the content of each Office 365 mailbox in a PST file and import it into the corresponding email inbox in Exchange.
  • Set up new Outlook profiles for each user with the right mailboxes added, leaving the current profiles so that users could go back to check their existing mailboxes if necessary.
  • Test each step first with a test account in Office 365 and a test mailbox on premises.

There were two options for getting the existing email/calendar/notes/task data out of Office 365. (Microsoft doesn't really make this step that easy; I wonder why?) I considered a third-party application from Lepide, but in the end, I opted for using built-in tools. This always makes me less worried because if there's a problem, at least I've only got to talk to Microsoft support.

The migration ^

The built-in method relies on eDiscovery to do a search of all data in a mailbox. We then export it to a PST file, which we then download. The steps are:

  1. Go to as an O365 administrator.
  2. Click on Permissions, admin roles, and then double-click on Discovery Management.
  3. Under Roles, click the + button, find Mailbox Import Export, and add it to the role.
Add the Mailbox Import Export role

Add the Mailbox Import Export role

  1. Under Members, add yourself to the role. (Global Administrators in Office 365 do not have this role by default.)
  2. Click compliance management in EAC and pick in-place eDiscovery & hold. (Note that this functionality will move from the EAC and the SharePoint management console in the near future to the consolidated console at
  3. Click the + sign to add a new search, give it a name, and click Next.
  4. Pick a mailbox. (I did each mailbox individually as that gave me some control over the download phase, but you can do multiple mailboxes in one search.)
  5. On the next screen, you can optionally filter based on dates, sender, etc. I chose all content.
  6. The next screen allows you to set legal hold; this is not required for this scenario.
  7. Finish will start the process in Office 365 of going through the entire mailbox and then gathering all the information into a PST file.
Click the button to install the PST Export Tool

Click the button to install the PST Export Tool

  1. Clicking the download button will install the eDiscovery PST Export Tool and ask you where you'd like to download the PST file. For this project, I chose not to enable deduplication and to include unsearchable items. After I clicked download, the project presented me with a string as a secure key to enter in the download tool. When I ran the same tool recently writing this article, it asked me for credentials instead. Note that if you have two-factor authentication (2FA) turned on for your account, you'll need to enter your app password for Outlook, not your ordinary password for Office 365.
The eDiscovery PST Export Tool

The eDiscovery PST Export Tool

  1. After downloading the PST for each mailbox, open an administrative PowerShell Exchange Shell on the Exchange server.
  2. The New-MailboxImportRequest only takes a universal naming convention (UNC) path to the PST file to import, so you'll need to share the folder where you've downloaded the files. Run:

    New-MailboxImportRequest -FilePath "\\Exch13\Exports\Test\08.18.2017-1840PM\Exchange\" -Mailbox Test

  3. The import into the mailbox will take some time, but you'll be able to track the progress in the Exchange Administrative Center.
  4. After importation of the data, be aware that it shows up in a subfolder. So if you want the imported messages to show up in the right folders, the user (or you) will need to move the messages from the imported inbox to the inbox in the mailbox, for instance. The same goes for Notes and Calendar items; users will need to move them all into the corresponding parts of their mailboxes.

I ran through all of these steps with a test mailbox (with some copied data added to give it some size) to verify that it would work for the real migration.

I started the migration on a Friday afternoon, exported and downloaded each mailbox in turn, and followed by importing them into the right mailboxes. Based on information from the users, I also went through all the shared mailboxes and assigned the correct permissions to each user who should be able to access the mailbox and have the Send As permission for it.

The reality ^

Nothing ever goes according to the plan though. It turns out that when you add a new email address on premises (and run a manual sync job), it still takes a few hours until the Symantec email hygiene solution accepts incoming email for that user as legitimate. So that took a bit of troubleshooting on the big day: the Monday after the weekend when I did all the exporting, downloading, and importing.

Out of habit I had also opted for cached mode in Outlook where it keeps a copy of the mailboxes in a local OST file. This makes Outlook much more resilient to the occasional network interruption. The problem was that, as I was setting up users' mailboxes, they were "missing" emails that simply hadn't synchronized to their OSTs yet. Worse, once they started using the shared mailboxes, users were seeing outdated versions of them, leading to confusion about whether users had replied to messages or not. Switching them to online mode for Outlook fixed this issue.

Nobody had mentioned email on phones, but of course I found out that a few users did need this access, so I sorted this out as well using the free Outlook app on iPhone.

The Fasttrack Outlook add-in was a highlight however; it simply picked up the right settings for each user as I created new Outlook profiles, so I had nothing to do to at all.

One lingering problem seems to be the occasional prompting for a password that Outlook is famous for, but other than that the users are happy.

The next project is migrating their LOB applications—controlled documents currently in SharePoint in Office 365 and other applications—from their shared server in the cloud to the on-premises Citrix servers for remote access. I have a feeling that project will make this one look like a walk in the park.

Win the monthly 4sysops member prize for IT pros


Users who have LIKED this post:

  • avatar

Related Posts

  1. James 3 months ago

    Thanks for a description of the process you went through. Its clear things are not always as easy as planned. I would be interested to hear the business's motivation for moving from Office 365 to the local Exchange, was there a performance component or was it an Economic one.


  2. Author
    Paul Schnackenburg 3 months ago

    Hi James,

    It was an economical decision that they looked at a couple of years ago. They're a not for profit so they get a very good deal on the on-premises licensing but (at the time) not such a good deal on Office 365 (for nearly 300 users).

    I suspect if you add-in the cost of the staff to manage the on-premises infrastructure that cost benefit might not be so clear but hey - the client is always right 🙂



  3. Rob 3 months ago


    Why not use free O365 licensing available for 501(c)(3) through TechSoup?



  4. Author
    Paul Schnackenburg 3 months ago

    Hi again Rob,

    I'm in Australia, not sure what the prices were when they decided. I wasn't privy to the financial details - that's just what they had decided.



  5. Javier 2 weeks ago


    I have a different migration.

    I have 50 users in Office 365 (on line) with  a domain (ie and I want to migrate all of hem to another domain (since my Company was bought), ie

    How can I do it?.



  6. Author
    Paul Schnackenburg 2 weeks ago

    Hi Javier,

    If it's only a matter of changing the domain, simply add another vanity domain to the tenant in the O365 console and change that domain to the primary one for your users emails / account names. Just like you did originally when you added "". See here and here

    Hope that helps,

    Paul Schnackenburg


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account