Delta migration explained
After you configure and start a migration job, CodeTwo Exchange Migration performs a full migration of the selected data from the source server to the target one. Once the full migration is finished, you can use the Rescan feature that scans the source server for:
- any items that were intentionally not migrated previously (for example due to applied time or folder filters),
- items that were created on the source server after the migration,
- items whose migration failed during previous attempt(s),
and migrate them to the target server.
This process is called delta migration, a feature that is mainly used in cutover and staged migrations. This article thoroughly explains the concept of how delta migrations are performed by the program and how your actions performed on the source server can affect the Rescan process.
Note that the Start and Rescan buttons have different functions in the program. When the migration process has been completed and you run the migration job again by using the Start button, the items that were not migrated in the previous migration run(s) (because they failed or did not exist on the source server) will not be migrated in this run either.
Each item is migrated only once
To prevent duplicates from being created on the target server, the program doesn’t migrate items that were modified on the source server after the migration. This is achievable because the application keeps its own local database, where it stores the information about which portions of data have already been transferred successfully. This applies, for example, to draft emails, appointments or public folder posts. However, keep in mind that copying or moving an item to another folder creates a new item in that folder, which will be migrated. On the other hand, the deletions of items from the source server also will not be reflected during delta migrations at all. Provided below are the most common scenarios regarding changes made on the source server after the migration and how these changes will affect the Rescan process:
- A new email has been received – the Rescan will migrate this email to the target server.
- An appointment date has been changed – the Rescan will not migrate that appointment item.
- A document has been copied from folder A to folder B – the Rescan will migrate the document from folder B to the target server. Consequently, there will be two copies of the document on the target server: in folder A (migrated previously) and B (migrated using Rescan). This duplicate is created because, from the program's point of view, the copied document is considered as a new item.
- An email has been moved from the Inbox folder to the Archive folder – the Rescan will migrate the email from the Archive folder. However, the email will not be removed from the Inbox folder on the target server. Consequently, there will be two copies of that email on the target server: in the Inbox folder (migrated previously) and in the Archive folder (migrated using Rescan).
- A calendar item has been deleted (moved to the Deleted Items folder) – the Rescan will migrate the calendar item from the Deleted Items folder (provided that this folder has not been excluded from a migration job – read more about the folder filter). However, the item will not be removed from the Calendar folder on the target server. Consequently, there will be two copies of that item on the target server: in the Calendar folder (migrated previously) and in the Deleted Items folder (migrated using Rescan).
- A task item has been deleted permanently (not only moved to the Deleted Items folder) – the Rescan will not migrate any item. However, the task item that has been migrated previously will remain in the Tasks folder on the target server.
- An email status has changed from unread to read – the Rescan will not migrate the email again (this would create a duplicate) nor update its status on the target server (the program cannot modify the data in your environment). If the email was marked as unread during the initial migration, it will still be marked as such after running the Rescan.
In addition, in case of a staged migration or similar migration scenarios, items excluded from being migrated by using a time filter will be migrated with the Rescan function once that filter is removed (or modified to include all or some of the items that were initially excluded from the migration job). For more information on how to edit a migration job and modify the time filter, see this article.
If you need to migrate items that have been modified on the source server, you can Reset mailbox migration state. However, you have to be careful since this option removes information about already migrated items for an entire mailbox. It is not possible to reset the data selectively so that only particular items or folders are affected. Instead, if you want to re-migrate only specific data, apply appropriate filters after resetting the mailbox migration state.
Migration information stored in a local cache
The information regarding items that were migrated between the source and target servers is saved by the program to a local cache. Thanks to that solution, even if you configure multiple migration jobs where you select the same pairs of mailboxes or public folders, the program will not migrate the same items again. This prevents the program from creating duplicates on the target server. In other words – target mailboxes are not scanned or checked in any way; the program checks the data in its local database instead.
However, the cached migration data is not synchronized between two or more instances of CodeTwo Exchange Migration, so migrating the same pairs of mailboxes / public folders will create duplicates on the target server.
Keep also in mind that changing the domain on the source or target server has no impact on the Rescan functionality. Using the Refresh email addresses option gives you an option to correct any broken relations between source and target mailboxes.
Target server is not scanned during delta migrations
Once the Rescan feature is used, CodeTwo Exchange Migration checks all items residing on the source server against the migration data stored in the program’s cache. This is done in order to determine which items haven’t been yet migrated and to migrate them. The program has no information about the data residing on the target server.
This means that in case you delete one, several or all items from the target server that were previously migrated with the program, these items will not be migrated again by using Rescan or by restarting the migration job. To be able to migrate these items, use the Reset mailbox migration state feature.