I’d add seperate the human (emotional) aspect from the facts. People have the right to be anxious about delays, it shows their commitment to the work provided (would be worse to get no emotions when issues are raised) Next, focus on issue resolution by taking things step by step. Important not to take all at once, as this might result in more failures. Go step by step, communicate very detailed and make sure all stakeholders are onboard. Identifying the root cause of the issues often provides 60% of the solution.

First action "Don't Panic". Doing a quick impact assessment with a plan for temporary workarounds (if any) and way to resolution is key for such issues. Building confidence with stakeholders that you completely understand the issues and impact of same and you have it under control for resolution helps to calm the stakeholders and get their confidence. if required you can assist stakeholders to out a response for their data consumers

Understand what is wrong and caused to flag data migration procedure. Be very parient to go through further to penetrate and give details of evidence of Data 'how it flows in migration'. Please accept if something went wrong and explain with alternative to stakeholders' not to panic and convince 'this will be fixed on within no time'

In order to calm stakeholders you need to do thorough investigation and provide as much information as possible by answering the questions below: 1. What is affected? 2. What are the next steps to get the data fixed? 3. What time will each step take? And of course, you need to keep them posted. It would be also good to do root cause analysis to make sure this will not happen in the future.

If you're data migration just flagged critical issues maybe calm isn't what you are looking for!! Presuming you have been following the migrate early and often approach this is data that has been recently entered or a recently changed sctyps or config. You might need to do manual fixes in source, pre migration or manual catch up activities after migration before go live or you might need to flag some records for next action resolution after go live. Either way you have some unplanned work. Fixing manually in any of these ways will de risk the cut over rather than scrypt or config changes which require testing. It comes at a cost that stakeholders need to decide on and if manual work is chosen, apply resources to.