Migrating Public Folders to Microsoft 365: The Complete Guide

Public folders are the part of an Exchange migration that everyone underestimates. Mailboxes get all the planning attention, and then three weeks into the project someone asks, "wait, what about the shared folders where accounting keeps twenty years of invoices?" and the schedule grows a new appendix.

The reason they surprise people is structural: public folders do not migrate with your mailboxes. They move through their own separate batch migration process, on their own timeline, with their own preparation steps and their own failure modes. If your organization uses them, they deserve a dedicated workstream from day one, and this guide is the shape of that workstream.

First, find out what you actually have

Public folder deployments are archaeological sites. Layers accumulate over decades: project folders from 2009, a company calendar nobody has opened since the person who maintained it left, and, buried among the fossils, two or three folders the business genuinely runs on. Discovery has to separate those layers:

• Total data size and folder count. Size drives sync time; folder count drives complexity. A tree of 40,000 tiny folders is harder to move cleanly than 100 GB in fifty folders.
• Mail-enabled public folders. These are the critical ones. A mail-enabled folder has its own email address, often something customer-facing like a sales or support address. Miss one and inbound mail to that address starts bouncing after cutover, which customers notice before you do.
• Permissions. Who can see and post to what. Permissions migrate, but broken or orphaned permission entries (pointing at long-deleted accounts) can cause migration errors, so they need cleaning first.
• Actual usage. Last-modified dates tell you which branches of the tree are alive. There is no reason to migrate, and forever after pay to store, folders nobody has touched in a decade.

Decide the destination before you copy anything

Migrating public folders to public folders in Exchange Online is fully supported, and for organizations with deep folder trees and Outlook-centric workflows it is often the right call: the user experience stays identical. But a migration is also the one natural moment to ask whether public folders are still the right container at all. The realistic destinations:

Mixed outcomes are normal and healthy: keep the deep reference tree in Exchange Online public folders, convert the two customer-facing mail-enabled folders into shared mailboxes, and let the dead branches retire to an archive export. What matters is deciding per folder, on purpose, before the copy starts.

How the batch migration actually works

For the supported public-folder-to-public-folder path, the mechanics look like this from a planning altitude:

1. Preparation and cleanup. Fix orphaned permissions, resolve folder-name problems (odd characters, duplicate paths), and take a snapshot of the folder structure, sizes, and permissions so you can verify the result against it later.
2. Mapping. The source tree is mapped onto one or more public folder mailboxes in Exchange Online, which is how Exchange Online hosts public folder content. Large trees get split across several mailboxes; the mapping decides which branches land where, within Microsoft's size limits.
3. Initial sync. A migration batch copies the folder hierarchy and content to Exchange Online in the background while the on-premises folders remain live and writable. Like mailbox syncs, this is bandwidth and throttling bound, so large trees take days.
4. Incremental syncs. The batch keeps catching up with changes until you are ready to finalize.
5. Finalization. This is the one genuinely user-visible moment: the source folders are locked (briefly read-only or inaccessible), a final delta copies across, and Exchange Online becomes the live home of the folders. Schedule it like a mini-cutover, outside business hours, and warn the folders' heaviest users.
6. Verification. Compare the migrated tree against your pre-migration snapshot: folder counts, item counts on key folders, spot-check permissions, and confirm users can post.

Mail-enabled folders need their own checklist

Mail-enabled public folders are where public folder migrations really bite, because they sit in the mail flow itself. For each one:

• Record its SMTP addresses (all of them, including old aliases still in the wild) before migration.
• Verify mail routing after migration: a message sent to the folder's address from outside must land in the migrated folder. During coexistence, routing between on-premises and Exchange Online for these addresses must be explicitly handled, and this is a common source of quiet mail loss.
• If the folder is being converted to a shared mailbox instead, move its addresses to the new mailbox at cutover and test both directions.
• Check for workflow dependencies: rules, distribution lists that include the folder address, and applications that send to it.

The traps we see most often

• Starting public folders too late. Because they run as a separate batch with their own long sync, folders started as an afterthought finish weeks after the mailboxes, leaving the old server alive purely to host them. Start the folder workstream alongside mailbox sync. The sequencing lives in our full migration checklist.
• Oversized folders and items. Individual items over the destination's size limits, and enormous single folders, generate per-item errors that someone has to triage. Better to find them in discovery than in the error report.
• Assuming the tree is worth moving wholesale. Every gigabyte of dead folders costs sync time now and clutter forever. Prune first.
• Forgetting the finalization lock. Users who live in a busy public folder will notice the read-only window. Tell them beforehand and it is a non-event; surprise them and it is an outage report.
• Old Exchange versions. Legacy servers like Exchange 2010 use the old public folder database architecture, and moving that content to modern public folder mailboxes in Exchange Online involves extra preparation, or in some cases third-party tooling. It is solvable, but it is not a checkbox.

Where this fits in the wider project

Public folders are one track of a larger move whose method and timeline are set by your mailboxes: see choosing your migration method and how long a migration takes for that context. The rule of thumb for planning: whatever elapsed time your mailbox migration needs, assume the public folder track runs in parallel and finishes at or after the end of it, and do not schedule the old server's decommission until the folder verification is signed off.

Handled early, public folders are just another batch to babysit. Handled late, they are the reason the "finished" migration still has a server humming in the closet in three months. The difference is entirely in when you start.