Подготовка данных к миграции: кто отвечает, как мерить качество и где тестировать

Подготовка данных к миграции — это работа до переноса: назначить владельцев объектов данных, измерить качество и согласовать пороги, очистить и сопоставить данные, прогнать пробные загрузки в отдельных тестовых контурах и заранее договориться о сверке и откате. Сам перенос занимает меньшую часть работы. Сроки срывают качество источника и отсутствие ответственных в бизнесе.

Коротко:

• У каждого объекта (контрагенты, номенклатура, остатки) есть бизнес-владелец с правом подписи.

• Качество меряют по шести измерениям, пороги фиксируют до первой загрузки (quality gates).

• Помимо продуктива нужны три контура (dev, тест миграции, препрод), ПДн на стендах маскируют.

• Пробных прогонов обычно три–четыре, последний служит репетицией переключения.

• Сверка трёхслойная: записи, контрольные суммы, бизнес-проверка.

Почему миграции данных срываются по срокам и бюджету

Миграции данных срываются не на загрузке, а на данных: плохое качество источника и отсутствие ответственных за объекты обнаруживаются поздно, когда исправлять дорого.

Миграция данных — это перенос данных из систем-источников в целевую систему с преобразованием структуры, форматов и справочников.

Оценка Gartner старая (около 2009 года), известна по пересказам Experian и Oracle, но её до сих пор цитируют.

Причины повторяются. Данные считают задачей IT, и спорные записи копятся до приёмки. Объём чистки угадывают по выборкам. «Остатки перенесены корректно» финансы, склад и IT понимают по-разному. Тестируют на синтетике. Окно cutover не репетировали.

Этапы миграции данных: от инвентаризации до переключения

Подготовка данных к переносу в новую систему укладывается в восемь этапов, половина из них заканчивается до первой загрузки. Фаза миграции данных в ERP-проектах занимает 4–8 месяцев и идёт параллельно с настройкой системы.

Стратегия миграции данных — это решение, переносить ли всё за одно переключение (big bang) или поэтапно: по юрлицам, площадкам или модулям. От неё зависят план миграции данных, число прогонов и окно переключения.

Аудит данных перед миграцией: что найти до первой загрузки

Аудит данных перед миграцией отвечает на вопрос, что и в каком состоянии лежит в источнике. Без него план строится на догадках. Сначала инвентаризация: какие объекты переносятся (НСИ, мастер-данные, транзакции, остатки, открытые документы, история) и где живут (legacy, Excel, смежные системы).

Профилирование данных: какие цифры получить

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

По каждому объекту на выходе нужны цифры:

• доля пустых обязательных полей (КПП у юрлиц, единица измерения у номенклатуры);

• число дублей по ИНН+КПП, артикулу, табельному номеру;

• «мусорные» значения: «тест», «не использовать», «111111», даты 01.01.1900;

• висячие ссылки: документы на удалённых контрагентов, остатки на несуществующих складах;

• записи без движения N лет.

Отдельно смотрят Excel-файлы, годами живущие рядом с учётной системой. Сюрпризов там больше.

Какие объекты проверять первыми

Первыми проверяют справочники и НСИ: контрагентов, номенклатуру, сотрудников, оргструктуру. На них ссылаются транзакции и остатки, и ошибка размножается.

Миграция НСИ — это перенос нормативно-справочной информации (классификаторов, справочников, мастер-данных) с приведением к структуре и правилам целевой системы.

Реальный объём чистки виден только после пробной загрузки (блог iFellow, 2026), поэтому первый прогон планируют как диагностический. Там и всплывают редкие коды, ручные правки прошлых лет, карточки в обход регламента.

Владельцы данных: кто за что отвечает в проекте миграции

За качество данных при миграции отвечает бизнес, за перенос — IT. Если владельца не назначили до аудита, решения о чистке и маппинге некому подписывать. Назначают его на каждый объект: у контрагентов и остатков они обычно разные.

Подрядчик владельцем быть не может: он не знает, какой из двух контрагентов с одним ИНН действующий. Спорное эскалируют по цепочке «data steward → бизнес-владелец → руководящий комитет» со сроком ответа.

Роли: бизнес-владелец, data steward, команда миграции, подрядчик

Владелец данных (бизнес-владелец) — это руководитель функции, который отвечает за объект данных, решает, что переносить и по каким правилам, и подписывает результат.

Data steward (стюард данных) — это специалист, который ведёт объект данных ежедневно: проверяет, исправляет, согласует спорные записи и готовит их к подписи владельца.

Команда миграции (IT) ведёт выгрузку, трансформацию, загрузку и стенды. Подрядчик даёт методологию, ETL, прогоны и сверку, но решений по данным не принимает.

Матрица RACI для миграции данных

RACI — это матрица распределения ответственности, где R исполняет, A отвечает и утверждает, C консультирует, I информируется.

Распределение — ориентир, его фиксируют в уставе проекта.

В SAP-проектах (блог SAP, 2014) валидацию каждого объекта подписывают до загрузки следующего.

Критерии качества данных и quality gates: какие пороги согласовать

Качество данных при миграции измеряют по 5–6 измерениям, и для каждого заранее согласуют порог, ниже которого объект к следующему прогону не допускают.

Quality gate — это контрольная точка, где объект данных проверяют по согласованным метрикам; без подписи владельца он дальше не идёт. Ставят их после очистки, после каждого прогона и перед cutover.

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

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

Очистка данных перед миграцией и что не стоит переносить

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

Основная работа — дедупликация. Два контрагента с одним ИНН и разными КПП бывают головной организацией и филиалом. Или дублем. Решает steward, подписывает владелец.

Золотая запись — это единая эталонная версия объекта, собранная из дублей по письменно зафиксированным правилам: реквизиты из одной карточки, адрес из другой.

Чистка в источнике надёжнее, правки при трансформации быстрее, но живут только в ETL.

Что не переносить в новую систему

Обычно в новую систему не берут:

• закрытых контрагентов без движения N лет (N задаёт владелец);

• неиспользуемую номенклатуру;

• технические и тестовые записи;

• дубли после слияния в золотую запись.

Закрытые документы глубже согласованной истории заменяют остатками и сальдо. Исключённое хранят в архиве на чтение столько, сколько требует учёт.

Маппинг данных: как описать правила переноса

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

Сопоставление полей при миграции оформляют таблицей с владельцем у каждого правила, справочники соответствий кодов ведут отдельно. Условный пример:

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

Тестовые контуры для миграции: какие нужны и какие данные в них держать

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

Тестовый контур — это изолированная копия целевой системы со своими данными и правами доступа, предназначенная для одной задачи.

Стенды бронируют заранее: в разгар проекта препрод нужен всем.

Обезличивание данных для тестовой среды и 152-ФЗ

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

Федеральный закон от 30.11.2024 № 420-ФЗ, действующий с 30.05.2025, ввёл оборотные штрафы за повторную утечку персональных данных: 1–3% выручки, не менее 20 млн и не более 500 млн руб. (ч. 15 ст. 13.11 КоАП РФ; buh.ru, 2024; Контур, 2025). Порядок маскирования и допуска подрядчиков согласуйте с юристами и ИБ.

Пробные загрузки (mock runs): сколько нужно и что меняется между прогонами

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

Тестовая миграция данных, или пробная загрузка (mock run), — это полный цикл выгрузки, трансформации, загрузки и сверки в тестовом контуре.

Dry run (репетиция cutover) — это финальный прогон с хронометражем по плану переключения.

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

Журнал дефектов — это реестр ошибок из прогонов: объект, причина, ответственный, срок и номер прогона, где дефект закрыт.

В SAP-проектах (блог SAP, 2014) пробные загрузки на части объектов заканчивают к системному тестированию, а финальную репетицию проводят на полном объёме в копии продуктива.

Сверка данных после миграции: три уровня проверки

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

Сверка (reconciliation) — это сопоставление данных источника и цели по заранее заданным правилам с отчётом о расхождениях.

Количество записей

Баланс записей по каждому объекту должен сходиться: выгружено = загружено + отфильтровано + отклонено (с причиной). Не сходится? Записи потерялись в трансформации.

Контрольные суммы

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

Бизнес-проверка

Владельцы смотрят выборку и проходят сквозные сценарии: заказ на перенесённого контрагента, документ по остатку, ОСВ. Итог — подписанный акт приёмки.

Cutover и план отката: как провести переключение без потерь

Cutover — это контролируемое переключение с системы-источника на новую систему в согласованное окно. Критерии go/no-go и порядок отката утверждают до его начала.

Data freeze (заморозка изменений) — это период, когда в источнике запрещено менять справочники и настройки, чтобы загружаемое совпало с проверенным.

Шаги cutover:

1. Утвердить план, окно и ответственных.

2. Объявить даты заморозки и простоя.

3. Заморозить справочники и НСИ.

4. Сделать резервные копии источника и цели.

5. Закрыть период, выгрузить начальные остатки.

6. Загрузить справочники, потом остатки и открытые документы.

7. Сверить, получить подписи владельцев.

8. Догрузить дельту.

9. Принять решение go/no-go.

10. Открыть систему, закрыть legacy на запись.

Параллельно две системы гоняют, когда ошибка дороже двойного ввода. Скажем, зарплату за первый месяц.

План отката миграции

Точка невозврата — это момент cutover, после которого откат дороже исправления ошибок в новой системе (например, пользователи уже провели в ней документы).

До точки невозврата действует rollback, после неё исправляют вперёд. В плане отката: резервные копии на момент старта, точка невозврата, ответственный за решение со сроком, процедура возврата пользователей в legacy.

Финальный cutover откатить трудно, поэтому валидацию подписывают пообъектно заранее (блог SAP, 2014). При смене подрядчика план отката и журнал дефектов входят в пакет передачи.

7 типовых ошибок при миграции данных

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

1. Данные — «задача IT». Спорное никто не решает → владелец на каждый объект до аудита.

2. Аудит после настройки. Маппинг переделывают → профилирование в первые недели.

3. Пороги не согласованы. Споры на приёмке → протокол порогов по объектам.

4. Переносят всё «на всякий случай». Чистят мёртвые записи → перечень «не переносить».

5. Один прогон на синтетике. Ошибки всплывают в продуктиве → три–четыре прогона, последний на полном объёме.

6. Реальные ПДн на стендах. Штрафы по 420-ФЗ → обезличивание до передачи.

7. Нет плана отката. Решают без критериев → go/no-go и rollback утверждены до cutover.

Чек-лист подготовки данных к миграции

Чек-лист из 20 пунктов проходят на входе в quality gate перед каждой пробной загрузкой и cutover.

Организация

• Реестр объектов с источником, объёмом, глубиной истории

• На каждый объект назначены владелец и steward

• RACI утверждена в уставе проекта

• Есть цепочка эскалации со сроками ответа

• Выбрана стратегия миграции (big bang или поэтапная)

Качество и очистка

• Профилирование по всем справочникам и НСИ

• Протокол порогов подписан по каждому объекту

• Правила золотой записи записаны

• Перечень «не переносить» подписан

• Маппинг подписан, версия зафиксирована

Контуры и прогоны

• Развёрнуты dev, тест миграции и препрод

• ПДн на стендах обезличены, порядок согласован с юристами

• Журнал дефектов ведётся

• Минимум три прогона, последний на полном объёме

• Прогон укладывается в окно cutover

Сверка и cutover

• Правила трёхуровневой сверки утверждены

• Баланс записей сходится по каждому объекту

• Акты приёмки подписаны

• Утверждены критерии go/no-go и точка невозврата

• План отката проверен на репетиции

Частые вопросы

С чего начать подготовку данных к миграции?

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

Кто отвечает за качество данных при миграции: IT или бизнес?

За качество данных при миграции отвечает бизнес-владелец объекта данных. Он решает, что переносить, и подписывает результат на каждом quality gate. Data steward ведёт объект ежедневно. Команда миграции и подрядчик отвечают за перенос, инструменты и стенды, но решений по данным подрядчик не принимает.

Сколько тестовых миграций нужно провести перед запуском?

Перед запуском обычно проводят три–четыре тестовые миграции (mock runs), включая репетицию cutover на полном объёме. Первая пробная загрузка выявляет ошибки маппинга и реальный объём чистки, последняя проходит в препроде с хронометражем окна переключения. Жёсткой нормы нет: число прогонов зависит от объёма и сложности данных.

Чем тестовый контур отличается от препрода, можно ли тестировать на копии продуктива?

Препрод отличается от тестового контура миграции тем, что близок к продуктиву по объёму данных и настройкам и нужен для финальной репетиции cutover. Тестовый контур служит для пробных загрузок и отладки маппинга на обезличенных данных. Тестировать на копии продуктива допустимо при маскировании персональных данных и разграничении доступа.

Как проверить, что данные перенеслись полностью и без ошибок?

Полноту и корректность переноса данных проверяют сверкой на трёх уровнях. Первый уровень: баланс записей (выгружено = загружено + отфильтровано + отклонено). Второй: контрольные суммы остатков, сальдо и количеств в разрезах складов, счетов и юрлиц. Третий: бизнес-проверка выборки записей и сквозных сценариев с подписанием акта приёмки.

Какие данные не стоит переносить в новую систему?

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

Что делать, если миграция прошла неудачно: как устроен откат?

Если миграция прошла неудачно до точки невозврата, систему возвращают из резервных копий источника и цели по утверждённому плану отката, а пользователей — в legacy-систему. Решение об откате принимает названный заранее ответственный по критериям go/no-go. После точки невозврата ошибки исправляют вперёд в новой системе.

Можно ли использовать персональные данные в тестовой среде?

Персональные данные в тестовой среде можно использовать только с соблюдением 152-ФЗ: размещение ПДн на стендах тоже считается их обработкой. На практике ФИО, паспортные данные, телефоны и адреса обезличивают до передачи на стенд и разграничивают доступ по ролям. Конкретный порядок стоит согласовать с юристом и службой ИБ.