This is the complete onboarding task flow for migrating public folders from Exchange 2007+ or Microsoft 365 to shared mailboxes in Exchange 2010+ or Microsoft 365. This document will walk you through the environment preparation and MigrationWiz steps necessary to perform your migration.
We recommend reading through the complete guide before starting the migration to understand the process, timeline, and prerequisites. You will see notes called out throughout the guide; pay attention to these, as they may provide information to avoid migration failure.
Complete each step in the order listed. If additional instructions are required, a link to a corresponding Knowledge Base article is provided.
MigrationWiz
MigrationWiz is a migration tool, not a syncing tool. If changes are made at the source after migration, they will not sync to the destination, nor will changes made at the destination sync to the source. We do not have “live” monitoring of changes (as with a sync agent) and we cannot handle scenarios such as conflict resolution without user interaction.
MigrationWiz supports the capability to share migration projects across a Workgroup. When the Project Sharing feature is turned on, all Agents besides those who are Inactive can view all migration projects. For more information, visit Project Sharing in MigrationWiz.
Prerequisites
Please consider the information below before choosing this migration type.
Licensing
Purchase Public Folder licenses to obtain an estimate of the number of Public Folder migration licenses required for your migration project and follow the directions in Estimating the Required Public Folder Migration License Count.
Licenses are released once payment has been received:
- Licenses are available immediately upon payment if you purchase via credit card.
- If you purchase via wire transfer (100+ licenses), the licenses will be available once payment is received and accepted.
- We do not accept purchase orders because of processing overhead.
In both cases, you will be notified by email that payment has been accepted and licenses are available in your account upon notification.
For more information on licensing, including coupon redemption and other licensing types, see our Which Migration License Do I Need? guide.
Purchase licenses by following the steps below.
- Sign in to your BitTitan account.
- In the top navigation bar, click Purchase.
- Click the Select button and choose the license type you need.
- Enter the number of licenses you want to purchase. Click Buy Now.
- Enter a Billing address if applicable.
- Click Next.
- Review the Order Summary and enter a payment method.
- Click Place Your Order.
Limitations
Consider the following limitations when performing this type of migration.
- App password usage, MFA/2FA, SSO, and ADFS are not supported for the migration admin account/service account being used by this endpoint.
- Exchange Web Services (EWS) must be enabled in both the source and destination for this migration type.
- Shared mailboxes require delegated permissions for access to folders. Currently, MigrationWiz does not update the source Public Folder permissions to the destination Shared Mailbox delegated permissions. Our development team is working on the fix, until then the destination Shared Mailbox delegate permissions need to be applied manually.
- BitTitan support does not offer post-migration guidance regarding the management and resolution of public folders on the source environment.
Migrated Items
Please click the bars below to check the migrated and non-migrated items. We are constantly working to create a better migration experience for you so these items may change over time.
Public Folders can only be migrated to other public folders or shared mailboxes. We do not migrate Public Folders to individual user mailboxes or Microsoft 365 Group mailboxes or vice versa. Mail-enabled public folders are not supported for destination endpoints that are Exchange On-Premise and will need to be mail-enabled manually. For additional details about items that are and are not migrated from public folders, see our Migrated and Not Migrated Items article.
Exchange 2010 SP1+ & Microsoft 365
Migrated
- Public Folders and Subfolders
- Mail Folders
- Calendar Folders
- Contact Folders
- Tasks
- Notes
- Journals
- User Permissions (Folder level only)
- Mail-Enabled Security Group Permissions (Default and Anonymous User Permissions are not supported) - Folder level only
Not Migrated
- Rules
Not Migrated in any Exchange Instance
- Email templates
- Email flags (if the destination is G Suite)
- Safe Sender/Block Lists
- Mail Settings
- Standalone documents stored in Mailbox Folders or Public Folders (Example: IPM.Document item types)
- System Public Folders
- StickyNote folders
- Delegated permissions
Not Migrated in Exchange 2007: Public Folder Permissions
Modern Authentication Requirements
The steps listed in the Obtain Client and Tenant ID Settings for Mailbox and Exchange Online Migrations section of the Authentication Methods Migrations KB apply to both the source and destination tenant when they are Exchange Online, in regards to Exchange Web Services (EWS) in mailbox, archive mailbox, and public folder projects. Use a Global Administrator for the configuration steps.
Please review the documentation before preparing the environment.
Prepare the Source Environment
Retirement of Exchange Web Services in Exchange Online
Microsoft has announced that Exchange Web Services (EWS) requests will start to be blocked in M365 tenants with a phased, admin controllable disablement beginning on October 1, 2026, and a final retirement date of April 1, 2027. We recommend reviewing the information outlined in Microsoft’s announcement for additional details.
We are taking the necessary steps to transition to Microsoft Graph API and ensure continued service without disruption. The transition to Microsoft Graph API will be completed before the final retirement date of EWS.
All migrations using EWS for Exchange Online (Microsoft 365) endpoints require following the steps under the Enable EWS Access in Exchange Online and Scoping EWS Access Before Retirement using EWSAllowedAppIDs sections of the migration guide for your particular migration scenario before you start your migration. These steps are required if your source, destination or both are Exchange Online (Microsoft 365).
Important
If you receive the following type of error in your project "Your migration failed while checking credentials. The request failed. The remote server returned an error: (403) Forbidden" check that you follow the steps correctly for Enabling EWS and adding your MigrationWiz EWS AppID to the EWSAllowedAppIDs list in your tenant using the steps below.
All PowerShell steps below use ExchangeOnline PowerShell and require a Global Admin to run the commands.
Enable EWS (Exchange Web Services) Access in Exchange Online
EWS access will be blocked if the following steps are not completed:
- Enable EWS at Organization level
- Enable EWS at User level
- Add the EWS Application using the tenant to the EWSAllowedAppIDs list (see steps below)
Ensure that the commands and steps below are followed to enable EWS in your tenant and prevent any unintentional interruptions to your migrations. For further information regarding this topic, please review the following Microsoft article. If you need assistance on this topic, please contact BitTitan's support team.
Commands to Enable EWS at Organization-level:
# Check current status:
Get-OrganizationConfig | fl EWSEnabled
# Enable EWS:
Set-OrganizationConfig -EWSEnabled $trueCommands to Enable EWS at User-level:
# Check a specific mailbox
Get-CASMailbox -Identity user@domain.com | fl EWSEnabled
# Enable EWS for a specific mailbox
Set-CASMailbox -Identity user@domain.com -EWSEnabled $true
# Enable EWS for ALL mailboxes (use with caution)
Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -EWSEnabled $trueScoping EWS Application Access Before Retirement using EWSAllowedAppIDs
Important
You must complete the Modern Authentication app registration steps outlined in the Authentication Methods for Microsoft 365 (All Products) Migrations article before running the commands below. The Application (client) ID generated during that process is the App ID you will add to the allow list using the steps below.
In preparation for EWS retirement, Microsoft has introduced EWSAllowedAppIDs, a tenant-level allow list that restricts EWS access to only the applications you explicitly approve. To ensure MigrationWiz continues operating without interruption, the steps below are required as of August 6, 2026. Starting October 1, 2026, Microsoft will block all EWS traffic for tenants where EWSEnabled is set to True at Organization-level and User-level, but no EWSAllowedAppIDs list has been configured. Only applications whose App IDs appear in the EWSAllowedAppIDs list will be permitted to use EWS with MigrationWiz.
For further information on EWSAllowedAppIDs, review Microsoft's article Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement.
Important Considerations Before Running any Commands
- Changes to the allow list can take up to 24 hours to take effect. Exchange Online servers refresh their in-memory cache once every 24 hours. Plan accordingly and add your App IDs for your migration well ahead of time before testing your App IDs or starting your migration.
- Verify after every change. Run the verify command after any add or remove operation to confirm the list is correct before assuming the change took effect.
Verify the Allow List:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDsNote
The -RetrieveEwsOperationAccessPolicy parameter is required. The allow list is not returned by a standard Get-OrganizationConfig call.
Warning
Always run the above command first, before creating or modifying the Allow List to ensure there is not an existing list already. If you perform the steps for creating the Initial Allow List on an existing list, you may erase the App IDs already in that list. If you verify that the list already exists with App IDs, move down to the Add an App ID to an Existing List step.
If a pre-existing list of EWS App IDs are present, make sure you copy or safely store those IDs before making any modifications to the EWSAllowedAppIDs list in the case you need to re-apply the App IDs.
Create the Initial Allow List:
If no allow list exists yet, create one by specifying one or more of the MigrationWiz EWS App IDs in a comma-separated string. This replaces any existing value, so include all App IDs you want to permit in a single command.
Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"Verify the Allow List:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDsImportant
Always verify the Allow List before and after making any modifications to your List.
If you need to add or remove an App ID for an already existing list, you must read the current list, compute the updated list, and then write the full value back using the Microsoft provided PowerShell commands below:
Add an App ID to an Existing List:
For $newAppId, use the App ID of the MigrationWiz EWS application for the project ("" included).
# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App ID to add
$newAppId = "99999999-8888-7777-6666-555555555555"
# Combine existing and new values
$updated = @($current, $newAppId)
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")Remove an App ID from an Existing List:
For $removeAppId, use the App ID of the MigrationWiz EWS application for the project ("" included).
# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the App ID to remove
$removeAppId = "99999999-8888-7777-6666-555555555555"
# Split the comma-separated list into individual App IDs
$appIds = $current -split ","
# Remove the specified App ID
$updated = $appIds | Where-Object { $_ -ne $removeAppId }
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")- Grant admin permissions
Grant Admin Permissions
- Grant elevated 'Organization Management' administrator role to the migrating administrator account. Refer to Assigning the Elevated Admin Role 'Organization Management' to a Public Folder Account for Migration.
- Ensure that the source administrator account has a mailbox enabled and is located on the same Exchange server as the source Public Folder database or mailbox.
- Ensure that the migrating administrator account has permission in all Public Folders (Read-only or "Reviewer" access rights should be enough). For more information, see Granting Necessary Permissions to Source Public Folders.
Prepare the Destination Environment
Retirement of Exchange Web Services in Exchange Online
Microsoft has announced that Exchange Web Services (EWS) requests will start to be blocked in M365 tenants with a phased, admin controllable disablement beginning on October 1, 2026, and a final retirement date of April 1, 2027. We recommend reviewing the information outlined in Microsoft’s announcement for additional details.
We are taking the necessary steps to transition to Microsoft Graph API and ensure continued service without disruption. The transition to Microsoft Graph API will be completed before the final retirement date of EWS.
All migrations using EWS for Exchange Online (Microsoft 365) endpoints require following the steps under the Enable EWS Access in Exchange Online and Scoping EWS Access Before Retirement using EWSAllowedAppIDs sections of the migration guide for your particular migration scenario before you start your migration. These steps are required if your source, destination or both are Exchange Online (Microsoft 365).
Important
If you receive the following type of error in your project "Your migration failed while checking credentials. The request failed. The remote server returned an error: (403) Forbidden" check that you follow the steps correctly for Enabling EWS and adding your MigrationWiz EWS AppID to the EWSAllowedAppIDs list in your tenant using the steps below.
All PowerShell steps below use ExchangeOnline PowerShell and require a Global Admin to run the commands.
Enable EWS (Exchange Web Services) Access in Exchange Online
EWS access will be blocked if the following steps are not completed:
- Enable EWS at Organization level
- Enable EWS at User level
- Add the EWS Application using the tenant to the EWSAllowedAppIDs list (see steps below)
Ensure that the commands and steps below are followed to enable EWS in your tenant and prevent any unintentional interruptions to your migrations. For further information regarding this topic, please review the following Microsoft article. If you need assistance on this topic, please contact BitTitan's support team.
Commands to Enable EWS at Organization-level:
# Check current status:
Get-OrganizationConfig | fl EWSEnabled
# Enable EWS:
Set-OrganizationConfig -EWSEnabled $trueCommands to Enable EWS at User-level:
# Check a specific mailbox
Get-CASMailbox -Identity user@domain.com | fl EWSEnabled
# Enable EWS for a specific mailbox
Set-CASMailbox -Identity user@domain.com -EWSEnabled $true
# Enable EWS for ALL mailboxes (use with caution)
Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -EWSEnabled $trueScoping EWS Application Access Before Retirement using EWSAllowedAppIDs
Important
You must complete the Modern Authentication app registration steps outlined in the Authentication Methods for Microsoft 365 (All Products) Migrations article before running the commands below. The Application (client) ID generated during that process is the App ID you will add to the allow list using the steps below.
In preparation for EWS retirement, Microsoft has introduced EWSAllowedAppIDs, a tenant-level allow list that restricts EWS access to only the applications you explicitly approve. To ensure MigrationWiz continues operating without interruption, the steps below are required as of August 6, 2026. Starting October 1, 2026, Microsoft will block all EWS traffic for tenants where EWSEnabled is set to True at Organization-level and User-level, but no EWSAllowedAppIDs list has been configured. Only applications whose App IDs appear in the EWSAllowedAppIDs list will be permitted to use EWS with MigrationWiz.
For further information on EWSAllowedAppIDs, review Microsoft's article Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement.
Important Considerations Before Running any Commands
- Changes to the allow list can take up to 24 hours to take effect. Exchange Online servers refresh their in-memory cache once every 24 hours. Plan accordingly and add your App IDs for your migration well ahead of time before testing your App IDs or starting your migration.
- Verify after every change. Run the verify command after any add or remove operation to confirm the list is correct before assuming the change took effect.
Verify the Allow List:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDsNote
The -RetrieveEwsOperationAccessPolicy parameter is required. The allow list is not returned by a standard Get-OrganizationConfig call.
Warning
Always run the above command first, before creating or modifying the Allow List to ensure there is not an existing list already. If you perform the steps for creating the Initial Allow List on an existing list, you may erase the App IDs already in that list. If you verify that the list already exists with App IDs, move down to the Add an App ID to an Existing List step.
If a pre-existing list of EWS App IDs are present, make sure you copy or safely store those IDs before making any modifications to the EWSAllowedAppIDs list in the case you need to re-apply the App IDs.
Create the Initial Allow List:
If no allow list exists yet, create one by specifying one or more of the MigrationWiz EWS App IDs in a comma-separated string. This replaces any existing value, so include all App IDs you want to permit in a single command.
Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"Verify the Allow List:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDsImportant
Always verify the Allow List before and after making any modifications to your List.
If you need to add or remove an App ID for an already existing list, you must read the current list, compute the updated list, and then write the full value back using the Microsoft provided PowerShell commands below:
Add an App ID to an Existing List:
For $newAppId, use the App ID of the MigrationWiz EWS application for the project ("" included).
# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the new App ID to add
$newAppId = "99999999-8888-7777-6666-555555555555"
# Combine existing and new values
$updated = @($current, $newAppId)
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")Remove an App ID from an Existing List:
For $removeAppId, use the App ID of the MigrationWiz EWS application for the project ("" included).
# Read the current allow list
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# Define the App ID to remove
$removeAppId = "99999999-8888-7777-6666-555555555555"
# Split the comma-separated list into individual App IDs
$appIds = $current -split ","
# Remove the specified App ID
$updated = $appIds | Where-Object { $_ -ne $removeAppId }
# Write the updated allow list back
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")- Use a global administrator account for the tenant. This can be an already created account or can be created specifically for this migration. The administrator account being used for the migration must have a licensed mailbox enabled in the tenant.
- Create the shared mailboxes and grant the destination administrator account Full Access permissions to the shared mailboxes. The steps to create these are defined in a TechNet article here.
- If the destination is Microsoft 365, increase the shared mailboxes maxsend and maxreceive size to 150MB. If the destination is Exchange, increase the message size limits.
Increase Message Size Limits
Increase the public folder quotas to Unlimited. The default Microsoft 365 Public Folder quota setting is 2GB, with the issue warning set to 1.7 GB. These steps are from our article Microsoft 365 Public Folder Migration FAQ.
- Open a PowerShell session and enter the following. Then press Enter:
$LiveCred = Get-CredentialInstall-Module -Name ExchangeOnlineManagementImport-Module -Name ExchangeOnlineManagementConnect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred - Enter the following command and press Enter. This will show you the current limits set on the public folder mailboxes:
Get-Mailbox -PublicFolder | fl Name,MaxSendSize,MaxSendSize - Enter the following command and press Enter. This will increase the MaxSendSize and MaxReceiveSize to the maximum allowed limits. (If there are items at the source that are larger than 150 MB, they will not migrate.)
Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -MaxReceiveSize 150MB -MaxSendSize 150MBAdditional details about send and receive size limits can be found in our Best Practices for Migrating On-Premises Exchange Public Folders article.
MigrationWiz Steps
The following steps will be performed in MigrationWiz.
- Create project.
- Set endpoints.
- Add items.
- Run Verify Credentials.
- Set Advanced Options.
Create a Public Folder migration project. Read the MigrationWiz Projects article for more information on project types and troubleshooting.
- Click the Go to My Projects button.
- Click the Create Project button.
- Select Public Folder as the migration type.
- Click Next Step.
- Enter a Project name and select a Customer.
- Click Next Step.
Set the source and destination endpoints by selecting Microsoft 365 Public Folders for the source endpoint and Microsoft 365 Public Folders for the destination endpoint.
Important
When configuring your endpoints, do not forget to complete the client ID and the tenant ID fields for the Source and Destination endpoints. Otherwise, you cannot save your project migration.
Once the information has been provided for both, the source and/or destination endpoint and the customer selects Save and Go to Summary, MigrationWiz performs an endpoint validation check.
This validation tests the administrator credentials entered into the project and the Modern Authentication setup only. If there is an issue, the screen redirects to the endpoint and provides an error message or flyout that can be selected for more information regarding the error.
Common Errors when Configuring Your Endpoint
For more information, review the AADSTS700016, AADSTS90002, and ADDSTS50126 issues on the Common Errors Using Modern Authentication page.
Add the items you wish to migrate.
- Select Add.
- Select Quick Add.
- Enter a forward slash ( / ) in the Root Folder Path field.
- Add the address for the shared mailbox in the Destination Email field.
We recommend this because it will migrate all Public Folders, and you will only need one Public Folder license per 10GB of data, regardless of the number of top-level Public Folders. Refer to Migrating all Public Folders from the Root Level Down
If migrating specific public folders to multiple shared mailboxes, select Add > Bulk Add and enter the full path of each source folder to be migrated in the Root Path field and the address of the intended destination shared mailbox in the Destination Email field.
If migrating to multiple shared mailboxes, open a ticket with Support using the Subject “Public Folders to Shared Mailboxes: License Audit”. Include the Project name, the total GB of source Public folder data to be migrated, and the number of destination Shared Mailboxes being migrated to. This will allow Support to make sure that you have the correct number of licenses to migrate without having to purchase extras.
Now that your project has been created and/or added for the Root Path, or the specific folders to be migrated have been added, run Verify Credentials from the Start menu in the MigrationWiz project.
Set Advanced Options
Important
The advanced option steps listed below should be followed in the order that they are entered as they are required for this migration scenario.
Support Tab
- RemoveFilterBasedOnFolderType=1 This support option is required if Public Folders contain items other than mail, such as calendar and contact items. This option stays in place for the entire migration process.
-
MustMigrateAllPermissions=1 This flag is required to migrate Public Folder permissions to a shared mailbox. This Advanced Option allows you to migrate all folder permissions, not only the system folders when migrating from Exchange 2010+ mailboxes as, by default, only systems folder permissions are migrated. We do not migrate Delegation, SendAs/SendOnBehalfOf permissions, or any permissions for the Default or Anonymous user accounts. For more information, see Migrating Public Folders to Shared Mailboxes.
Note: This option stays in place for the entire migration process.
Default Options for Microsoft 365 Endpoints
By default, some fields are view-only. In other words, you cannot edit or remove them from the support options page. To edit them, you need to edit the source or destination endpoint of your project.
Among these default options, you can find ModernAuthClientIdExport, ModernAuthTenantIdExport, ModernAuthClientIdImport, and ModernAuthTenantIdImport.
The support options above are required when configuring your endpoint.
Warning
You cannot update the default Advanced Options, in case you try to modify or add new ones the following message arises.
Performance Tab
- Set value for Licensing/Maximum licenses to consume per item per pass licensing count. Default = 1. This allows up to 10GB to be migrated. Example: If migrating all Public Folders, using the forward-slash ( / ), and the total data size = 78GB, then increase this value to 8 (otherwise the migration will pause at 10GB). See MigrationWiz Licenses.
Source/Destination Tab
- Select the option for Migrate to: Shared Mailbox. This will be found under either Destination: Exchange Server 2007+ or Destination: Microsoft Office 365, depending on what was selected when creating the destination endpoint.
- Set the value for Migrate Permissions For from New Folders Only to New folders and existing folders.
Run Migration
- Set first pass Project Advanced Options. For more information on running multiple passes, see Pre-Stage vs. Big Bang Strategy for Public Folders.
- Set Date Filter to migrate items older than six (6) months. Date range filters can be set under Advanced Options.
- Perform the first pass for items older than 6 months by running a Full Migration.
- Set second pass Project Advanced Options.
- Set the Date Filter to migrate items newer than six (6) months.
- Perform a second pass for items newer than 6 months by running a Full migration.
- Request the migration statistics. Click the bar chart icon on the MigrationWiz dashboard to receive an email containing all the project migration statistics.