Sign in with Microsoft
Sign in or create an account.
Select a different account.
You have multiple accounts
Choose the account you want to sign in with.


If you're using batch migration or serial migration to migrate public folders from Microsoft Exchange Server 2007 or Microsoft Exchange Server 2010 to Exchange Server 2013, Exchange Server 2016, or Exchange Online, data loss may occur if all the folder replicas aren't on the primary database (the primary database server that the migration service connects to). All data that is at first present in folders that are being migrated are copied, but any incremental changes that are posted after the initial sync may be lost.  

Example scenario

Assume that you have two public folder databases, PFDB1 and PFDB2, that are running on Exchange 2007 or Exchange 2010 servers. Also, you have two folders, F1 and F2. Folder F1 has a replica on PFDB1 and folder F2 has a replica on PFDB2.

When you start the migration and specify PFDB1 as the database to connect to in the New-MigrationEndpoint cmdlet, all data from folders F1 and F2 is copied during the initial sync (as shown in Figure 1). This occurs even though PFDB1 doesn't have a local replica of folder F2.

After this first sync process, you prepare for the final sync and you start to complete of the batch. You expect that any data that's added to folder F1 and F2 after the first sync should be copied over during the final sync.

Figure 1. Folder F1 and F2 from the source is copied to the destination during the first sync.


During incremental and final sync, the incremental data from folder F2 isn't copied to modern public folders (as shown in Figure 2). This is because PFDB1 is specified as the endpoint. The batch status is displayed as synced. However, any new data that was added to folder F2 after the first sync isn't copied to modern public folders.

Additionally, if there are any new folders that are added to PFDB2 after first sync (folder F3 in Figure 2), the content of those folders won't be copied either. (This is true even though folder F3 is displayed in the hierarchy).

Figure 2. Incremental data to folder F1 is copied, and changes to folder F2 are not copied. Although data in newly added folder F3 is not copied, the folder appears in the hierarchy. 


The fixes are available in Cumulative Update 13 for Exchange Server 2013and Cumulative Update 3 for Exchange 2016


Before you start batch migration, make sure that all public folders have a replica on the public folder database that will be specified as the source for migration. Also, make sure that the public replication is in sync.

Workaround for the example scenario

To work around this issue, add a replica of folders F2 and F3 on PFDB1, make sure that public folder replication is in sync, and then start batch migration. This makes sure that the incremental data is copied (regardless of which replica it's originally written to). 

We realize that this workaround won't work for some customers because of the size of the public folder deployment. If you're in this situation, we recommend that you wait until the issue is fixed before you run a migration.


Q:When did this issue start to occur?
A: This issue was first observed in Exchange Server 2013 Cumulative Update 1, Exchange Server 2016 RTM, and Exchange Online.

Q: What data did I potentially lose?
A: In the MRS report, search for "Folder hierarchy changes reported in source," select the first "Folder hierarchy changes reported in source" item that's listed, and then select the date and time that's associated with the log. Any data that's added to folder F2 or any new folders that are added to PFDB2 after this time is lost.

Q: I still have my Exchange Server 2007 or Exchange Server 2010 public folder databases in their locked state since we migrated to Exchange Server 2013, Exchange Server 2016, or Exchange Online. Can I still migrate my lost data?
A: Only a manual copy of the data is possible.

Q: My migration took weeks to reach the ready-to-complete state. Do I have to start over?
A: No, you don't have to restart the public folder migration. When the fixes are completed and the updates are installed on your server (or on the Exchange Online servers, if you're migrating to Exchange Online), the migration can be picked up from where it is now and it will migrate the remaining data. You may have to restart the migration batch. However, when you do this, the process looks for changes and doesn't start over. A migration batch starts over only if you delete and then re-create it.

Need more help?

Want more options?

Explore subscription benefits, browse training courses, learn how to secure your device, and more.

Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.

Was this information helpful?

What affected your experience?
By pressing submit, your feedback will be used to improve Microsoft products and services. Your IT admin will be able to collect this data. Privacy Statement.

Thank you for your feedback!