Целостность данных при миграции SaaS: методы сверки и валидации

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

Целостность данных при миграции между SaaS — это не галочка «импорт завершен успешно». Это доказательство, что данные перенесены полностью, не исказились, сохранили связи и продолжают подчиняться бизнес-логике. По данным Gartner, до 83% проектов миграции данных не укладываются в сроки, выходят за бюджет или проваливаются. Причины чаще всего скучные и дорогие: качество данных, ошибки маппинга, слабая сверка, вера в то, что CSV-файл сам себя спасет.

Почему миграция ломается не на API, а на данных

Инженеры любят обвинять API. Иногда заслуженно. Rate limit на 10 запросов в минуту, пагинация без стабильной сортировки, экспорт «все поля» только через поддержку, вложения отдельным архивом через три дня. SaaS-платформы умеют быть гостеприимными как турникет в метро в час пик.

Но большинство провалов начинается раньше. В источнике.

Старая система годами копила мусор: дубли клиентов, сделки без владельцев, кастомные поля с одинаковыми названиями, статусы из эпохи предыдущего директора по продажам, email в поле телефона, телефон в комментарии, комментарий в названии компании. Пока это лежит внутри одного SaaS, бизнес как-то приспособился. После переноса в другую модель данных вся эта археология начинает стрелять.

Типовые антипаттерны я видел десятки раз:

1. Миграция «как есть» без аудита источника. Команда переносит не бизнес-данные, а цифровой ил. Потом удивляется, что новая система работает хуже старой.

2. Сверка только по количеству записей. Было 120 000 контактов, стало 120 000 контактов. Значит, успех. Нет. Возможно, у половины контактов перепутались владельцы, а даты последнего касания превратились в локальное время сервера в другом часовом поясе.

3. Игнорирование связей. Клиент есть. Сделка есть. Но сделка больше не связана с клиентом. Формально обе записи перенесены. Практически бизнес получил кашу.

4. Ручная проверка «на глаз». Открыли десять карточек. Вроде нормально. На миллионной строке тихо умерло поле с налоговым идентификатором. Узнают об этом не инженеры, а бухгалтерия. И не в лучший день.

5. Слепая вера в встроенный импорт SaaS. У многих платформ импорт действительно удобный. Для малого объема, простой структуры и спокойной совести. Для боевой миграции с историей, вложениями, ролями и транзакциями одного мастера импорта мало.

Импорт без сверки — это не миграция. Это лотерея с интерфейсом.

При переносе между SaaS проверке подлежат не только основные таблицы вроде клиентов и сделок. В нормальном проекте я выделяю минимум пять категорий данных, потому что каждая ломается по-своему:

Это не академическая классификация ради красивой таблицы. Это способ не забыть то, что потом больно восстанавливать из бэкапов, логов и переписки с вендором.

Три контрольные точки: до, во время и после

Проверка целостности не начинается после миграции. Если команда впервые задумалась о сверке, когда пользователи уже открыли новую систему, поезд ушел. Возможно, еще не с рельсов, но уже подозрительно дымит.

Нормальный цикл валидации держится на трех точках: до миграции, во время переноса и после финальной загрузки.

До миграции: аудит источника и фиксация эталона

Pre-migration этап — самый недооцененный. Он скучный. Там нет красивого деплоя, нет новой платформы, нет ощущения прогресса. Зато именно там решается, будет ли потом ад.

На этом этапе нужно зафиксировать, что именно считается исходной правдой:

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

Особенно важны контрольные суммы. Подготовка checksum до начала переноса позволяет после миграции проверить целостность за часы, а не за несколько дней ручного шаманства. Да, в SaaS не всегда можно посчитать checksum прямо на стороне источника. Иногда приходится выгружать данные пакетами, нормализовать порядок полей, приводить даты и строки к единому формату, а уже потом считать хэши. Оверхед есть. Зато потом не нужно спорить, «похожа» ли новая база на старую.

Технически полезно разделять два вида эталона:

1. Структурный эталон. Схемы, поля, типы, обязательность, допустимые значения.

2. Содержательный эталон. Реальные значения, агрегаты, контрольные суммы, связи, бизнес-состояния.

Структурная проверка не гарантирует логическую корректность. Новая система может принять поле amount как число, но это не значит, что сумма в правильной валюте и относится к правильной сделке. Схема довольна. Бизнес плачет.

Во время миграции: контроль процесса, а не молитва логам

In-migration контроль нужен, чтобы не обнаружить катастрофу в конце. Особенно при больших объемах, когда перенос идет батчами, очередями, воркерами, ретраями и прочей инженерной живностью.

Что отслеживать в процессе:

• сколько записей отправлено, принято, отклонено и поставлено на повтор;
• какие ошибки повторяются системно, а не случайно;
• есть ли дрейф по времени обработки батчей;
• не меняется ли источник во время переноса, если нет заморозки записи;
• не появляются ли дубли при ретраях;
• корректно ли сохраняется соответствие старых и новых идентификаторов.

Последний пункт критичен. Таблица соответствия ID — это не временный мусорный файл, который можно удалить после «успешного» импорта. Это страховочный трос. Старый customer_id должен надежно сопоставляться с новым ID в целевой системе. Без этого связи, вложения, активности и интеграции начинают жить своей жизнью.

Если миграция идет без downtime, появляется отдельная боль: изменения в источнике во время переноса. Здесь нужны стратегии: freeze-окно, инкрементальная догрузка, журнал изменений, повторная сверка измененных записей. Нельзя честно обещать, что любая SaaS-миграция пройдет без простоя. Иногда короткое окно заморозки дешевле, чем неделя разбирательств с расхождением заказов.

После миграции: сверка результата и приемка бизнесом

Post-migration этап — не «пользователи посмотрят и скажут». Пользователи, конечно, скажут. Обычно громко. Но это уже не валидация, а эксплуатационный инцидент.

После переноса нужна формализованная сверка:

• базовое совпадение количества записей;
• сравнение контрольных сумм;
• проверка критичных полей;
• валидация связей;
• проверка бизнес-правил;
• выборочный просмотр ре