Summary

On December 31, 2020, FastTrack Migrations team is implementing Data Consistency Scoring reporting for customers performing Exchange, Gmail, and IMAP migrations. This change applies to commercial tenants on Jan 1, 2021. The change will occur to government tenants on Jan. 29th, 2021.

Historically, we've used a configurable parameter called the "BadItemLimit" to define the number of items you are comfortable with dropping during a migration. These bad items generally are inconsistencies in metadata that can result in a user being failed during a migration if the limit is not set arbitrarily high. However, setting bad item limits extremely high runs the risk of not alerting you when there are might be significant amounts of truly bad items.

Inconsistencies pose a risk of data loss. These inconsistencies can occur during almost any migration, whether from on-premises Exchange Servers, Public Folders, PST file imports, G Suite migrations, or third-Party IMAP Servers. With DCS, when you attempt a migration, any inconsistencies between the source and target data stores will count towards the Data Consistency Score (DCS). This score is then used to determine whether an Exchange Online migration will complete successfully or if intervention is needed.

Impact

1. Customers that are currently in pilot and/or velocity will receive a banner notice at the TOP of the FastTrack Portal related to this change. Banner will begin to display on the FastTrack portal starting Dec 14, 2020.
2. DCS updates to the FastTrack Portal Learning Center will be published on the week Dec 18th.
3. Migration Event email communications will include DCS scoring for Investigate and Poor marked mailboxes.
4. Submissions of Bad Item Limits (BIL) or Large Item Limits (LIL) are no longer required. Adding these BIL or LIL parameters to any batch after the BIL/LIL feature is disabled will cause the batch to fail. Exchange Product Team will disabled the BIL/LIL feature by Jan. 15th, 2021 but maybe subject to change. If customer requires the use of BIL or LIL this requires an escalation in order to flight the feature that makes BIL and LIL parameters available to the tenant. However, flighting this feature for the tenant requires a justification by the customer which should include:
   • Clear description of the issue and at what step DCS is causing the issue
   • The exact failure that the migration batch is running into
   • Batch name/ID and tenant name should be included in the ticket
   • A high level classification of blocking vs non-blocking issue for the migration.

If the BIL/LIL exception is rejected, the customer must proceed with their migration batch using DCS. DCS does the calculation for you based on various thresholds. Microsoft is constantly tuning these thresholds to ensure that problematic data loss does not occur during migrations.

1. Mailboxes rated as POOR will require a support case to be opened for Remediation. Keep in mind that this is an issue with the source mailbox (on prem) and it will be the customers responsibility to correct the issue with the mailbox.
2. Mailboxes rated as INVESTIGATE have two options:
   1. Customer CAN approve the batch as complete and accept the data loss.
   2. Customer can review the reported issue that flagged the mailbox in the INVESTIGATE category, correct the issue, and reschedule that mailbox in a subsequent batch. The customer is ultimately responsible with correcting the issue with the on premises mailbox.

Action Required

Please make your customers aware of the change. DCS reporting will be implemented on December 31, 2020.

If you would like more information on DCS, please read the official documentation: Data Consistency Scoring