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