Common Pitfalls of Public Folder Migrations

At first glance, Public Folders appear to be easy to migrate. They’re a part of Microsoft Exchange. They have their own database. If they’re modern public folders, they exist within mailboxes, which means they’re part of a Database Availability Group (DAG). The DAG should be able to easily migrate over. It’s because of this that Public Folders are often the last part of Exchange to migrate. The success of their migration is assumed based on the ease of the mailbox migration. However, as you move head first into Public Folders you quickly realize that migrating public folders is anything but easy.

Here are some of the most common pitfalls for migrating Public Folders to Office 365:

1. We have Modern Public Folders on premise, so we will just copy the DAG. Office 365 is the same, right?

   It’s true, Modern Public Folders are the same functionally in Office 365. However, there are many sizing requirements that need to be met prior to migrating. Microsoft Exchange allows for many more folders overall as compared to Office 365. So, if your folder hierarchy doesn’t fit nicely, you will find yourself needing to map out the distribution of your public folder content manually.

2. Public Folders migrate just like Mailboxes. Copy the content to Office 365, continue to pull over delta’s, then cut-over when ready.

   It’s understandable that anyone would have this impression of a Public Folder Migration. After all, if the mailbox migration was that easy, why should you worry about the Public Folders? The migration process is a completely script-drive process. Microsoft provides a series of PowerShell scripts and commands to tackle a Public Folder migration. There is no GUI available when doing a public folder migration manually. It’s also difficult to confirm what data has made it over to the destination. If an item didn’t migrate, it can be extremely difficult to track it down.

3. Public Folder Migrations will not interrupt end users.

   If you’re using the Microsoft scripts or another solution that uses the Microsoft Migration API, then you could be in for a painful experience. You must lock down your Public Folder source to read-only for the span of the migration. If you have a very small amount of data (less than a GB), you might be able to get away with this. However, this type of migration is single-threaded, so larger data sets can take days, weeks, or even months!

4. There’s no difference when migrating mail-enabled Public Folders.

   Surprisingly, the standard Public Folder Migration process does not copy all of your mail-enabled Public Folder attributes. You could lose valuable information during the migration, so you must proceed with caution. Microsoft scripts will remove the mail-enabled Public Folders from the source, and you can’t revert back once run. Most third party solutions use the same scripts and migration API, so they’re also not going to protect you from these problems.

5. Office 365 Exchange Online will auto-provision new Public Folder mailboxes once you hit the size limit.

   The auto-provisioning feature is a hands-off approach to Public Folder mailbox management. Microsoft will detect when you are nearing capacity and create a new Public Folder mailbox to rollover to. However, this process wasn’t designed to work during a migration. The auto-provisioning process can take up to two weeks to complete! Public Folder mailboxes cannot be added while your tenant is auto-provisioning another Public Folder. This is why knowing the sizing requirements in Office 365 is critical.

If you are concerned about these pitfalls, then please contact us. We can make your Public Folder migration work the way you expect it to.