Symptoms
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.
Issue
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).
Resolution
The fixes are available in Cumulative Update 13 for Exchange Server 2013and Cumulative Update 3 for Exchange 2016.
Workaround
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.
FAQ
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.
