Public Folder migration to Office 365

Public folder size limits in Office 365

Microsoft enforces a few hard ceilings that shape how a public folder migration to Office 365 should be planned. A single tenant can hold up to 1,000 public folder mailboxes, and the hierarchy itself can grow to roughly 1 million folders. Each public folder mailbox is capped at 100 GB in most plans, with the underlying hierarchy size kept inside a 1 TB working ceiling. Items that exceed Microsoft’s per‑message size limit (typically 150 MB) won’t move regardless of the tool. EdbMails reads the source structure ahead of the run and flags folders likely to bump into these limits, so the split across target mailboxes can be planned cleanly instead of discovered mid‑migration.

Mail‑enabled public folders

Mail‑enabled public folders carry attributes that matter long after the migration finishes — primary SMTP address, proxy addresses, alias, display name, and the directory object that lets the folder receive external mail. EdbMails preserves these attributes as part of the public folder migration to Office 365, so existing mail flow to those folders continues to work once cutover happens. Folders that aren’t mail‑enabled on the source stay that way on the target. If a folder needs to become mail‑enabled post‑migration, that’s a one‑line PowerShell change against the target tenant — no re‑migration required.

Public folder permissions preservation

Permissions are usually the part that breaks in a public folder migration done by hand. EdbMails carries the client permission list across for every folder in the hierarchy — Owner, Publishing Editor, Editor, Author, Reviewer, and any custom roles — resolved against the matching user objects on the target tenant. Nested folders inherit the same way they did on the source, so a permission set defined three levels up doesn’t need to be reapplied folder by folder. Default and Anonymous permissions also move across as configured, which matters for folders that rely on Anonymous “Contributor” access for external posting workflows. Mappings between source and target users are handled automatically when UPNs match, with a manual override available for renamed accounts.

Public folder vs. Shared mailbox vs. Microsoft 365 Group

The question that often surfaces partway through a public folder migration is whether the destination should be a public folder at all, or whether the content would be a better fit somewhere else.

Public folder — still the right answer when teams rely on a shared hierarchy in Outlook, when long‑running archives of mail need to stay together, or when a deeply nested folder tree underpins a workflow. Visible in Outlook’s public folder tree, indexed for search, and supports mail‑enabling.

Shared mailbox — a better fit when the content is mostly mail traffic to a single address (support@, info@, sales@) and the team needs to triage as a group. Up to 50 GB without a license attached, which makes it the cheapest destination by far. EdbMails handles public folder to shared mailbox migration directly for teams that want to drop the public folder architecture entirely.

Microsoft 365 Group — the modern choice when the content is collaborative and the team is going to use Teams, SharePoint, and Planner anyway. The shared inbox is paired with a SharePoint site, a OneNote notebook, and a Planner plan out of the box. Less useful for pure email archives, more useful for active project work.