Migrations with Data Consistency Score (DCS) – more than you ever wanted to know!

The_Exchange_Team 

I scrolled though the 25? pages of this article and I'm not sure I see the value.

Every mailbox migration of a significant size where the systems have been in place for a while has "corrupted" items that do not get migrated. But if you are using well maintained Microsoft Exchange servers, Microsoft Outlook clients and Microsoft-supported OWA clients, the responsibility for the "corruption" can only lie with Microsoft for failing to maintain the integrity of these items and allow them to reach the nebulous state of "corrupted". There is no option that I have seen to check for "corruption" prior to the migration and no Microsoft mechanism that I have seen to repair the "corruption" induced by Microsoft apps.
The net result is that admins end up having to either set the "bad" item limit to a higher number to avoid the Microsoft induced "corruption", then let the mailbox migrate or set the "bad" item limit to zero, let the migration fail, then review the logs for any "corrupted" items and go back and address them individually in each users mailbox. The rerun the repaired mailbox. That's very very time consuming.
If you raise the "bad" item limit to allow the migration to complete you are then not migrating the "corrupted" items. In the past I've reviewed many of these reportedly "corrupted" items in user mailboxes and I've never seen anything apparently "corrupted" about any of them.
But lets think about what happens when you don't migrate any of these "corrupted" items. You have then chosen to effectively and very deliberately, delete messages from a user mailbox - i.e you have deleted user data. During the course of a larger migration you may end up deleting hundreds or thousands of user messages - all deliberately. This is a serious problem, not only for compliance and legal reasons but you may also be deleting very important user messages which may have financial or other lasting implications.
Did I miss something or is there still no way for Microsoft to identify and repair "corrupted" items that were obviously left "corrupted" by their own software?
Or is the recommendation to review all 25 pages of this article for each "corrupted" message that you find and gather more information about it but still not fix it and again delete user data ?
Sorry I'm not seeing anything of practical use to address Microsoft-"corrupted" items but a technical rabbit hole. Please let me know if I missed your solution to the aforementioned problem.