In my opinion this has to be a joined effort to find a solution, involving the person who is doing the migration, the MM and CO consultant.
It is easy to blame each other if something went wrong, but a migration is long process, especially an IDOC to IDOC migration invoives 100 or even 1000 of fields.
Some fields are not even visible in the material master.
We do a test migration in a test environment, this has to be validated by the project team, after approval and probably some fixes, the next load is done to a system where we do integration testing. And here we may encounter even other errors which require further fixes before it is finally approved to be loaded to a production system.
Who's fault it is when data are loaded inconsistent to production is hard to say. Why wasn't the error discovered in 2 tests before?
further it depends on the aggreements you have for outsourced activities. e.g. if you ordered a high professional who has done it already many times before and knows that the mapping rarely covers all fields and circumstances. or if you just asked to get it done and overestimated the quality of the rules given to the externals.
I am currently in a huge migration project, and I got the rules for customers, field by field, but still I get everyday new rules and important information was not given . e.g. that a customer in the old SAP had company code data, but the account group in the new system does not need them.
Have all sit together to clarify requirment, and search for best way to resolve it.
(a new idoc for the same material number overwrites existing data, if you are not yet live and have not done some manualy subsequent changes, then a new migration run could be executed to overwrite the inconsistent materials)