Planning a Public Folder to SharePoint Online Migration

A successful public folder migration to SharePoint Online does not begin when you press a start button in a migration tool. It begins weeks or months earlier, with a structured planning process that maps what you have, decides where it is going, and resolves every dependency before any data moves.

Organizations that skip planning and go straight to migration tend to encounter the same problems: broken permissions, disrupted mail flow, user complaints about missing content, and costly rollback operations. Organizations that plan properly execute faster and with fewer incidents.

This guide walks through the seven phases of a well-planned public folder to SharePoint Online migration.

Phase 1: Audit Your Source Environment

You cannot plan a migration from data you do not have. The first step is a complete audit of your Exchange public folder environment.

The audit should capture:

•       Total number of public folders
•       Hierarchy depth and structure
•       Size by folder – total and average item size
•       Item counts by folder
•       Permission structures – who has access to what, and whether permissions are inherited or explicitly set
•       Mail-enabled public folders – their addresses, routing configurations, and usage patterns
•       Last access dates – to identify which folders are actively used and which are dormant
•       Content types – email items, documents, calendar items, contact folders

This data is the foundation of every subsequent decision. A migration plan built without it is a plan built on assumptions. ExchangeSavvy’s Public Folder Analyzer automates this audit process – capturing folder counts, sizes, permissions, mail-enabled folders, and last-access data across your entire Exchange hierarchy before migration planning begins.

Phase 2: Decide What to Migrate and What to Archive

Not everything in your public folder environment belongs in SharePoint Online. Last-access data from your audit will typically reveal a significant proportion of content that has not been opened in years. Migrating that content to SharePoint creates unnecessary migration work, inflates storage costs in the destination, and pollutes the SharePoint environment with dormant content.

Before migration, categorize content into three groups:

•       Migrate: Actively used content that belongs in SharePoint Online as a live, accessible resource
•       Archive: Content that must be retained for legal or compliance reasons but is not in active use – this can be moved to a lower-cost archive rather than to SharePoint Online
•       Delete: Content that has no retention requirement and no ongoing value – this should be deleted before migration, not after

Getting sign-off from business stakeholders on what falls into each category before migration begins prevents disputes and rollback requests after migration completes.

Phase 3: Map the Source Hierarchy to the SharePoint Structure

This is the most time-consuming planning phase, and it cannot be automated. Every branch of the public folder hierarchy needs to be mapped to an equivalent SharePoint Online structure – a site, a document library, a folder, or some combination.

A few mapping principles:

•       Top-level public folders that represent distinct business areas (Finance, HR, Legal) typically become SharePoint sites
•       Second-level folders within those areas typically become document libraries or lists
•       Deeper nesting beyond 3-4 levels in SharePoint should be questioned – SharePoint’s search and navigation work better with flatter structures
•       Folder names should be reviewed for URL compatibility – Exchange public folder names frequently contain characters that are not valid in SharePoint URLs

Document the mapping in a migration manifest – a spreadsheet or structured document that shows, for each source folder, the exact destination URL in SharePoint, the permission mapping, and the migration status. This becomes your tracking document throughout the project.

Phase 4: Plan the Permission Migration

Public folder permissions in Exchange use role-based access: Owner, PublishingEditor, Editor, PublishingAuthor, Author, NonEditingAuthor, Reviewer, Contributor, None. SharePoint uses a different model based on permission levels: Full Control, Design, Edit, Contribute, Read, View Only.

You need a mapping from Exchange roles to SharePoint permission levels for each folder in your migration manifest. The mapping is not always one-to-one – some Exchange roles have no direct SharePoint equivalent and require a judgment call.

Key decisions to make in advance:

•       Will you replicate the exact Exchange permission structure in SharePoint, or simplify it?
•       Will broken inheritance from Exchange be preserved in SharePoint, or normalized to inherited permissions?
•       How will you handle permissions assigned to individual users (rather than groups)? SharePoint permission management is significantly easier with groups.

Permission decisions made during planning are far cheaper than permission fixes made after users report access issues in production.

Phase 5: Handle Mail-Enabled Public Folders Separately

Mail-enabled public folders require a specific sub-plan within the broader migration project. For each MEPF, you need to decide what replaces its mail routing function in the destination environment.

Common replacement patterns:

•       Shared mailbox: Best for public folders used as shared inboxes where email arrives and is read by multiple people. The shared mailbox receives email and users access it through Outlook.
•       Microsoft 365 Group: Best for public folders used for team collaboration – the group provides both email routing and a connected SharePoint site for document storage.
•       Distribution group: Best for public folders used as simple distribution targets where the content is forwarded on rather than stored.

For each MEPF in scope, document the replacement approach, configure it in advance, test mail routing end-to-end before cutover, and communicate the change to the users who depend on it.

ExchangeSavvy’s Public Folder Connector simplifies migrations from Public Folders to SharePoint Online and Shared Mailboxes while preserving folder hierarchy and supporting a smooth transition away from Exchange Web Services (EWS).

Phase 6: Run a Pilot Migration

Never run a full production migration without a pilot. Choose a portion of the public folder hierarchy that is representative but not business-critical – a department that is cooperative with testing, a folder tree of moderate size and complexity – and migrate it completely through the full process.

Use the pilot to:

•       Validate that your hierarchy mapping produces the SharePoint structure you intended
•       Confirm that permissions migrated correctly
•       Test mail routing for any MEPFs in the pilot scope
•       Measure migration throughput to produce an accurate timeline estimate for the full migration
•       Identify any unforeseen issues before they affect the entire environment

Document everything that goes wrong in the pilot and resolve it before proceeding. Issues found in a pilot are learning opportunities. Issues found in a production migration are incidents.

Phase 7: Execute, Validate, and Decommission

With planning complete and a successful pilot behind you, production migration can begin. The execution phase has four stages:

Incremental Sync

Begin migrating content to SharePoint Online while the source public folders remain live. The migration tool should perform an initial bulk load followed by incremental syncs that keep the destination current. Users continue working in the source environment during this phase.

Cutover

On the scheduled cutover date, stop writes to the source public folders, run a final incremental sync, and redirect users to the SharePoint destination. The cutover window should be as short as possible – hours, not days – to minimize disruption.

Validation

After cutover, validate that content is accessible in SharePoint, permissions are working correctly, mail flow is functioning for MEPFs, and users can find what they need. Validation should be performed by both IT and representative business users.

Decommissioning

Do not decommission source public folders immediately after cutover. Keep them in a read-only state for a defined hold period – typically 30 to 60 days – while users confirm they have everything they need in SharePoint. After the hold period, decommission and archive or delete the source content.

For content categorized as archive-only in Phase 2, consider moving it to SharePoint Online archiving rather than deleting it outright – this preserves compliance retention requirements without cluttering your active SharePoint environment.

ExchangeSavvy’s Public Folder Analyzer helps you assess your Public Folder environment before migration, while the Public Folder Connector simplifies moving content to SharePoint Online and Shared Mailboxes with preserved folder hierarchy and a streamlined migration experience. Visit ExchangeSavvy to learn more about planning your migration before Exchange Web Services (EWS) reaches end of life.