Данные не сходятся после переноса: как мигрировать без сюрпризов в цифрах

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

Так выглядит перенос «как получилось». Сняли дамп, залили, поправили строки подключения, поздравили себя. Не было плана сверки, не было окна дельты, не было владельца качества данных. Облако тут ни при чём — облако лишь ярче подсветило бардак переноса.

Когда заказы, остатки и пользователи разъезжаются, бизнес теряет не «технический комфорт», а операционную способность: нельзя честно обещать клиенту срок, нельзя закрыть день в учёте, нельзя доверять отчёту.

Самое неприятное, что внешне система может выглядеть живой. Страницы открываются, формы сохраняются, мониторинг зелёный. Ломается смысл данных — а это больнее простого даунтайма.

Именно поэтому критерии приёмки миграции должны быть про данные, а не сводится к HTTP 200 на главной.

Как разъезд данных проявляется в жизни

Сценарий первый — переключение без дельты. Основной объём перенесли ночью, а утренние заказы продолжали писаться в старую базу. Их «потом догонят». Не догнали. Часть потерялась, часть внесли руками с ошибками.

Сценарий второй — разные правила трансформации. В старой системе статусы «1/2/3», в новой — текстовые перечисления. Маппинг сделали на глаз. Часть заказов уехала в «неизвестный статус», автоматика склада остановилась.

Сценарий третий — справочники и связи. Пользователи переехали, но роли и привязки к организациям — нет. Товары переехали, но единицы измерения и штрихкоды «почти». Внешне таблицы полные, по смыслу — каша. Отчёты сходятся только если очень сильно хотеть.

Сценарий четвёртый — тихие дубли. Один и тот же клиент или заказ создаётся повторно из-за повторной загрузки без идемпотентности. Менеджеры начинают «чистить базу», и история окончательно расползается.

Ошибки, из которых растут сюрпризы после D-day

Считать миграцию законченной в момент «приложение открылось». Не делать контрольные суммы и выборки «до/после» по ключевым сущностям. Доверять одному прогону без повторной сверки через сутки. Переносить всё одним махом вместо волны критичных контуров. Отключать старую систему слишком рано, «чтобы не мешала».

Ещё хуже — чинить расхождения точечными правками в боевой базе без журнала. Через неделю никто не вспомнит, почему у заказа вручную поменяли склад и кто утвердил эту правку.

Отдельная ловушка — поручить сверку «потом аналитику». Аналитик увидит симптомы через отчёты, когда операционный ущерб уже нанесён. Сверка должна быть частью переключение, а не постскриптумом.

Что должно быть в миграции, кроме «перелить БД»

Нормальный перенос данных — это проект с критериями приёмки. Для заказов, остатков, пользователей, платежей заранее фиксируют, что значит «сходится»: количество записей, суммы, контрольные выборки, отсутствие дублей, целостность связей. Пороги допустимых расхождений тоже фиксируют заранее — иначе вечный спор «это мелочь или катастрофа».

Технически часто нужны инструменты репликации или захват изменений, а не только разовый дамп. Разовый снимок хорош для старта. Дельта и повторные прогоны нужны, чтобы догнать изменения, накопленные во время миграции. Без этого переключение всегда будет лотереей.

Отдельно проектируют откат: не лозунг «вернёмся на старое», а проверенная процедура с понятным допустимым объёмом потери данных. Если отката нет, команда будет бояться честно признать проблемы и начнёт маскировать их руками.

Не менее важно назначить владельца качества данных на период миграции. Без роли, которая имеет право остановить переключение при красной сверке, «успех» снова объявят по факту открывшейся главной страницы.

Как вытянуть ситуацию, если данные уже разъехались

Остановите хаотичные ручные правки. Зафиксируйте источники истины на период расследования: какая система master для заказов, какая — для остатков, какая — для пользователей. Снимите срезы и постройте сверку по ключам: идентификаторы, номера документов, суммы, статусы, метки времени.

Разделите расхождения на классы: не доехало, доехало дважды, доехало с кривым маппингом, живёт только в одной системе. Для каждого класса — свой метод ремонта и проверка. Критичные потоки (оплата, отгрузка) чинят в первую очередь; «красоту» справочников — потом.

Дальше внедряют контролируемый догон: репликация или повторная выгрузка, идемпотентная загрузка, журнал применённых пакетов. Только когда сверка стабильно зелёная несколько циклов — можно говорить о завершении миграции.

• определите master-системы и ключи сверки до любых правок;
• считайте не только «число строк», но суммы и связи;
• используйте дельту и репликацию вместо веры в один дамп;
• ведите журнал исправлений, запретите тихие правки на проде;
• не выключайте старый контур, пока критерии приёмки не выполнены.

Бизнес-результат нормальной миграции

Когда данные совпадают, работа становится более эффективной: склад правильно резервирует товары, финансы закрываются без дополнительных усилий, поддержка видит полную историю клиента. Облако начинает давать то, за что его выбирали — управляемость и масштаб — а не бесконечный разбор переноса.

Быстрые и некачественные миграции обходятся дороже из-за потери заказов и доверия, чем тщательное планирование сверки.

Полезно заранее договориться с бизнесом о «зелёном свете»: какие сверки обязаны быть зелёными в момент переключения, какие можно дочистить в течение суток, какие — в течение недели. Такая договорённость спасает от ложного ощущения финиша.

Если после переноса цифры уже разъехались или вы только планируете переключение, опирайтесь на подход миграции в облако со сверкой, дельтой и критериями приёмки — а не на надежду, что «дамп зайдёт целиком».

Успех миграции измеряется не скриншотом главной страницы. Он измеряется тем, что заказы, остатки и пользователи совпадают в системах, которым бизнес обязан верить каждый день.