Migrating Public Folders and Shared Mailboxes to Microsoft 365

User mailboxes get all the attention in a migration plan. Public folders and shared mailboxes are where the company's institutional memory lives: the sales inbox, the contracts folder from 2009, the calendar everyone books the conference room on. They also have their own migration paths, limits and licensing rules.

This post covers both: how modern public folders move to Exchange Online in a batch, and how shared mailboxes behave during and after the migration.

First, decide whether public folders should move at all

Public folders were built for a world without SharePoint, Teams and shared mailboxes. Before you migrate them, look at what they contain. A folder of scanned invoices is a SharePoint document library. A discussion folder that three people post to is a Teams channel. A folder that receives mail and gets answered by a team is a shared mailbox. A folder nobody has touched since 2015 is an export to PST and a line in the retention log.

Migrating everything as-is keeps the sprawl and adds the Exchange Online public folder limits on top. Migrating only what is used, and converting the rest, is more work now and less pain later. Run the statistics and sort by last modified time to see what is real.

Get-PublicFolderStatistics -ResultSize Unlimited | Sort LastModificationTime | Format-Table FolderPath, ItemCount, TotalItemSize, LastModificationTime
Get-PublicFolder -Recurse -ResultSize Unlimited | Where-Object { $_.MailEnabled } | Format-Table Identity, MailEnabled

Modern public folder batch migration

Exchange 2013 and later use modern public folders that live inside mailboxes, and Exchange Online supports a batch migration for them. Microsoft publishes a set of scripts that generate the mapping between your source folders and the target public folder mailboxes, sized to keep each target under the Exchange Online limits. The migration runs as a batch, syncs incrementally while users keep working on-prem, and finishes with a lock-and-complete step.

The order is: sync the mail-enabled public folder objects to Exchange Online so addresses resolve, export the folder statistics and build the mapping file, create the public folder mailboxes in the cloud, create the migration batch, wait for it to reach Synced, then lock the on-prem folders and complete. During the lock, users cannot open public folders, so schedule it for an evening.

The scripts change between Exchange versions. Download the current set for your source version from Microsoft and read the accompanying document before running anything.

Sync mail-enabled public folders to Exchange Online with Sync-ModernMailPublicFolders.ps1, or confirm Entra Connect is syncing them.
Run Export-ModernPublicFolderStatistics.ps1 to produce the size report.
Run ModernPublicFolderToMailboxMapGenerator.ps1 with a target mailbox size to produce the mapping CSV.
Create the target public folder mailboxes in Exchange Online, the first with HoldForMigration.
Create the migration batch with the mapping file and the hybrid endpoint.
When Synced, lock the source, complete the batch, verify, then unlock the cloud folders for users.

New-Mailbox -PublicFolder Mailbox1 -HoldForMigration:$true
New-MigrationBatch -Name PFMigration -CSVData ([System.IO.File]::ReadAllBytes("C:\PFMigration\PFMap.csv")) -SourceEndpoint PFEndpoint -NotificationEmails admin@domain.com
Start-MigrationBatch PFMigration
Get-MigrationBatch PFMigration | Format-List Status, TotalCount, SyncedCount

# On-prem, at the lock step
Set-OrganizationConfig -PublicFolderMailboxesLockedForNewConnections $true

# Exchange Online, to finish
Complete-MigrationBatch PFMigration
Set-OrganizationConfig -PublicFoldersEnabled Local -RemotePublicFolderMailboxes $null

Limits that decide the mapping

Exchange Online caps each public folder mailbox and the total number of them per tenant, and Microsoft adjusts these numbers over time. Check the current service description before building the map. The mapping script accepts a maximum mailbox size and splits folders across mailboxes to stay under it, so a large hierarchy ends up spread over several mailboxes.

Items over the 150 MB message limit will not migrate. Calendar and contact folders move, but forms-based folders and custom views often do not survive. Folder permissions migrate as long as the users exist in the cloud. Permissions granted to users who were never synced are dropped silently, so review the mapping report for warnings.

Shared mailboxes

Shared mailboxes move exactly like user mailboxes in a hybrid batch, and they keep their type. The rules that matter are on the licensing side. In Exchange Online, a shared mailbox up to 50 GB needs no license. It needs a license if it grows past that, if you want an online archive on it, or if you place it on litigation hold. Users who need it open in Outlook get Full Access, and with automapping on, the mailbox appears in their profile without setup.

A common cleanup during migration is converting user mailboxes of departed employees into shared mailboxes so the license can be released. That works in either direction with a single cmdlet. Also decide, per mailbox, whether the team wants Send As or Send on Behalf, since the two behave differently in the From line.

No license under 50 GB, no archive, no hold.
Full Access with automapping for the people who work it; Send As for teams that reply as the mailbox.
Sign-in should stay blocked on the shared mailbox account, and it should not be excluded from MFA policies by accident.
Convert departed users to shared to release licenses, after any hold requirement is checked.

Set-Mailbox -Identity sales@domain.com -Type Shared
Add-MailboxPermission -Identity sales@domain.com -User jane@domain.com -AccessRights FullAccess -AutoMapping $true
Add-RecipientPermission -Identity sales@domain.com -Trustee jane@domain.com -AccessRights SendAs

Frequently asked questions

Can public folders migrate while users are still on-prem?

Yes. The batch syncs in the background and users keep using the on-prem folders. Only the final lock and complete step takes the folders offline, usually for an evening.

Should I turn public folders into Microsoft 365 Groups instead?

For discussion-style folders, often yes. Microsoft provides a separate batch process for migrating public folders to Groups. For document folders, SharePoint is a better fit. Only keep public folders for what genuinely behaves like a shared folder tree.

Does a shared mailbox need a license after migration?

Not if it stays under 50 GB with no archive and no litigation hold. Exceed any of those and it needs an Exchange Online license like a user mailbox.

Takeaway

Treat public folders as a chance to retire what is dead and relocate what belongs in SharePoint or Teams, then batch migrate the rest with Microsoft's scripts and a mapping that respects the cloud limits. Shared mailboxes move with the users and cost nothing under 50 GB. Both are easier to sort out before the migration than after.