Improving Migrations Using Data Consistency Scoring

FYI in case anyone is back wondering the same.  It seems as though you can still override the Data Consistency Score by changing the limits on the batch itself while also doing Set-MoveRequest -BadItemLimit.

I also notice the Set-MoveRequest cmdlet in the EXO v2 PS module (v2.0.3) has been plastered with some double Write-Warning's about the fact that -BadItemLimit -LargeItemLimit parameters are going away.

Example of the double Write-Warning special

>Set-MoveRequest User@Domain.tld -BadItemLimit 40
WARNING: When an item can't be read from the source database or it can't be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are
 requesting Exchange not copy such items to the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox.
WARNING: The request is currently being managed as a part of a migration batch.  Changes to the request may be overwritten by the Migration Service or could impact the status expressed by the
migration batch or migration user.
WARNING: Setting a bad item limit may conceal unexpected data loss.  Please consider using the Data Consistency Score feature by not specifying the Bad or Large Item Limits.  Setting bad item
limits will be disallowed in the near future, even when the threshold (0) has not been exceeded.
WARNING: The request is currently being managed as a part of a migration batch.  Changes to the request may be overwritten by the Migration Service or could impact the status expressed by the
migration batch or migration user.
WARNING: Setting a bad item limit may conceal unexpected data loss.  Please consider using the Data Consistency Score feature by not specifying the Bad or Large Item Limits.  Setting bad item
limits will be disallowed in the near future, even when the threshold (0) has not been exceeded.

That 1x each of the original warning with -BadItemLimt, then 2x the usual warning about the move being part of a migration batch, and then 2x the new warning with the threat of the coming change.  So it definitely must be a serious threat.  That's 5 warnings, making for 1 large text wall of yellow.

I feel like the manual override should not be discontinued.  It should simply be updated in documentation that sometimes "BadItems" are not just corrupted items which are unsalvageable, sometimes they are indeed salvageable or even just worthwhile of letting the user know about.  Why the harsh discontinuance of these two significant features is beyond me.  Central Bad-Decisions'Ville.