Exchange Public Folder Migrations with MigrationWiz

Updated on 17 August 2016

Last month, I was in search of a method to migrate public folders from Exchange 2013 hybrid deployment to Office 365.  My research proved fruitless as there are plenty of articles available for Exchange 2007/2010 to Office 365 public folder migrations but nothing for 2013 to Office 365.  Queries were sent out to the community.  And come to find out, Microsoft doesn’t have a current “native” method to migrate modern public folder content in Exchange 2013 to modern public folders in Office 365 Exchange Online (as stated by Brian Day, SPM on the Microsoft Exchange team).  Brian is known as one of the foremost authorities regarding public folders in Exchange.

 

As luck would have it though, Jethro Seghers of BitTitan responded stating they have a solution.  Man! I love Twitter and how quickly the community can respond to someone in need.  There is a solution available through the MigrationWiz product suite that is specifically designed for Exchange 2007 (and newer) public folder migrations to Office 365.

 

After contacting Jethro, he set me up with some licenses so I could test out their public folder migrations product.  I reviewed the Public Folder Migration Guide for hybrid (or Public Folder Migration Guide for non-hybrid) and then logged into my BitTitan account to launch the MigrationWiz portal.

I have a couple of lab environments I’ve been using for PF migrations specifically; one is Exchange 2013 hybrid and the other is Exchange 2010 hybrid, and both have public folders with data.  The PF mailboxes were created previously in both tenants.

After logging into the portal, I went through the process of creating a public folder project, with the source being my on premise environment and the destination being the Office 365 tenant…

 

Licensing

Once the project was set, I added folders via “Auto Discover Items”.  One thing to understand here is that ‘Auto Discover Items’ will essentially automatically discover the on premise public folder structure and assign licenses accordingly.  Licensing of public folder migrations is fairly straightforward but we must have this understanding when referring the following screenshot of a sample PF structure…

 

Licensing is basically this… One license is assigned per “First Level” folder.  A first level folder is the set of top folders just under the PF root folder (“All Public Folders”).  Additional licenses are used after every 10GB of PF data is migrated.  Therefore, referring to the screenshot above, 3 licenses would be assigned based on the folder structure with less than 10GB of data to be migrated.

However, if we configure our project with “Quick Add”, instead of “Auto Discover Items”, we can target specific public folders within our environment.

 

And when we target the source PF “Root Folder Path” explicitly using ” / ” (which is represented by “All Public Folders” in the screenshot), only one license is used regardless of subfolder structure.

 

The only caveat being the amount of PF data migrated.  Again, every 10GB of data migrated will use a license.

In both environments, the root folder path was selected, and each environment has less than 1GB of data.  Therefore, only one license was used for each public folder migration project.

I think that pretty much covers licensing as far as I understand it.

 

Migration

When it came time to perform the migration, I was impressed with the experience.  Why?  Well, I had a lot of questions and I received answers immediately.  And when Jethro couldn’t answer a question, he got me in touch with someone who could … the lead developer, Scott Head.  Let me explain.

I first performed a Trial Migration.  With this task the folder hierarchy was created in full fidelity (permissions and folder types), and specific folders that were mail-enabled on premise were mail-enabled in Exchange Online.

During the first Full Migration test run (for the Exchange 2013 hybrid), I noticed not everything was migrated as I expected.  Of all of the items in the public folders, only mail items were migrated.  In the public folders there is a mixture of item types.  For example, in the ‘IT Department’ folder there are mail items and note items; and in the ‘IT Contacts’ folder there are contacts and groups.

A second full migration pass was performed and, again, not everything moved.  What I noticed is that note items in a mail items type folder did not migrate.  Could it be that only the mail items in a mail item type folder will migrate?  So, I was determined to prove this theory.  I created a note items type folder, created some notes in that folder and performed another migration.  Sure enough, the note items were successfully migrated.  I then asked and found that, at the time, only items that matched the folder created with the same item type would be migrated.  Fair enough.  But I have hundreds of customers with a mixture of item types in a single public folder.  And in one of my mail type folders, there are thousands of note items.

I explained the scenario to Jethro and asked if I was missing something.  He got back to me a bit later stating the lead developer was going to make an option available that will allow multiple item types from one folder to be migrated to the associated O365 folder.  I felt like it was Christmas, to get that kind of attention.  Apparently, there are advantages to owning the full product stack.

A couple of days later, I received an email stating to add (and save) the following text in the Support Options area of the project’s Advanced Options…

RemoveFilterBasedOnFolderType=1

This is what the text looks like when entered in the portal…

 

This command essentially removes any filter restriction based on folder and item type to allow all of the items to be migrated in their full integrity.

It was time to test out the new option.  Again, I performed a full migration and this time without issue; all items (regardless of their type) were successfully migrated to Office 365.

 

Observations

One thing that I thought of during this process is that this tool essentially provides a way for any organization to have PF data exist in both their on premise environment and Exchange Online during any type of mailbox migration.  Not that one would necessarily want this because changes in Office 365 cannot be synchronized back on premise.  But think of it, unlike migrating from a legacy Exchange environment to Exchange 2013 the public folder data can be present and accessible in both on premise and Office 365 locations.  For me and my customers, this is a huge win.

 

Caveats

During the migration of contact items, distribution (contact) groups did not migrate because it is not supported.  This article explains why BitTitan does not migrate groups.

 

Conclusion

I am constantly looking for ways to make my job easier but was frustrated to find that Microsoft doesn’t have a native way to migrate public folders data when those PFs reside in an on premise Exchange 2013 environment.  MigrationWiz showed me the way and I am a believer.  And I didn’t have to manually create folders or permissions or perform a dreadful export to a PST file.

While there are other solutions to migrate public folders to Office 365 Exchange Online, I’m going to place MigrationWiz at the top of the heap.  It is a simple, easy, and clean way to quickly migrate that necessary data to Office 365.

Thanks to Jethro, Scott and BitTitan for your great product and outstanding service.

 

Reference(s):

• Public Folder Migration Guide (MigrationWiz)
• Why are Personal Distribution Lists not migrated? (MigrationWiz)
• Easily Migrate Public Folders in Exchange 2013 to Office 365