Разбор начинают со сценариев изменения структуры базы и служебной таблицы, куда инструмент миграций записывает применённое. Читают её критически: такие таблицы допускают правку и очистку записей об ошибках, а изменения, внесённые вручную или автоматическим приведением схемы, в них вообще не попадают. Поэтому вывод «изменение применили тогда-то» подтверждают ещё и журналами самой базы, резервными копиями и историей репозитория.
Дальше сопоставляют состояние данных до и после и проверяют альтернативные объяснения: изменение схемы, ошибка в прикладном коде, ручное вмешательство, сбой при переносе, повторная обработка сообщений. Отдельно смотрят, соответствовал ли порядок работ заявленному: обкатывали ли изменение на испытательном стенде, снимали ли резервную копию перед применением, предусматривался ли откат.
Сохраните резервные копии и журналы базы за спорный период в первую очередь: без состояния «до» объём утраты обычно установить нельзя. Учтите, что в этих копиях лежат данные ваших клиентов, поэтому состав и период выгрузки ограничивают тем, что нужно для ответа, а порядок обращения с ними согласуют заранее — при назначенной экспертизе через суд или орган расследования.