Загрузка завершилась без ошибок, количество строк совпало, новая система открывается. Но часть заказов потеряла клиентов, остатки материалов округлились, а оплаченные обязательства выглядят неоплаченными. Технически файл перенесён; бизнес ещё не может доверять результату.
Миграция заканчивается тогда, когда данные правильно интерпретируются, рабочие связи сохраняются, а открытые обязательства можно продолжить. Для этого нужны пробная загрузка, контрольные сверки, управляемое переключение и заранее проверенный путь возврата.
Определите, что переносится и зачем
Разделите данные на справочники, текущие операции, историю и вложения. Для каждой группы назначьте владельца, период, источник истины и способ проверки.
Необязательно переносить всю историю в рабочие формы новой системы. Иногда старые завершённые документы достаточно сохранить в доступном архиве. Но решение должно учитывать поиск, обязательства и требования к хранению, а не только удобство разработчика.
Для текущих операций перечислите состояния, которые нельзя потерять: открытый заказ, частичная отгрузка, резерв материала, незавершённая работа, ожидаемое согласование. Они определяют возможность продолжить процесс на следующий день.
Составьте карту соответствия полей. Укажите преобразование дат, единиц, кодов, валют, пустых значений и статусов. Одинаковое название поля не гарантирует одинаковый смысл в двух системах.
Подготовьте реестр преобразований
Заполненный пример для учебного заказа:
- Источник: заказ 0471, клиент К-204, количество 100, отгружено 40.
- Назначение: заказ с сохранённым внешним идентификатором 0471 и ссылкой на нового внутреннего клиента.
- Состояние: «Частично выполнен», если такое соответствие утверждено.
- Открытый остаток: 100 − 40 = 60 единиц.
- Связи: позиции, отгрузки, ответственный, вложения.
- Проверка: пользователь видит общий объём, выполненную часть и оставшееся обязательство.
- Исключение: если отгружено больше заказанного, запись попадает в разбор, а не исправляется молча.
Для каждого преобразования храните правило и пример. Особенно внимательно проверяйте округление денежных сумм и количества. Нельзя без согласования заменять неизвестное значение нулём: «нет данных» и «значение равно нулю» означают разное.
Сделайте пробную миграцию
Используйте копию данных в разрешённой среде и воспроизводимую последовательность действий. Зафиксируйте версии исходной схемы, преобразований и целевой системы. Сохраните список отклонённых записей с объяснениями.
Первая проба отвечает не только на вопрос о корректности, но и о длительности. Замерьте выгрузку, передачу, преобразование, загрузку, индексацию и сверку отдельно. Время появления последней строки ещё не означает готовность пользователей к работе.
Документация AWS DMS по проверке данных показывает, что проверка результата миграции является отдельной операцией сопоставления источника и назначения. Здесь важен сам принцип; использование AWS для вашего проекта из него не следует.
Повторите перенос после исправления правил. Ручное изменение нескольких записей на стенде не доказывает, что следующий запуск даст тот же результат.
Сверяйте не только количество строк
Проверки удобно распределить по уровням.
Полнота: сколько объектов ожидалось, сколько загружено, сколько исключено по согласованному правилу, сколько отклонено.
Связи: у каждой позиции есть заказ, у заказа — допустимый клиент, у движения — материал и склад. Найденные нарушения должны иметь владельца решения.
Значения: суммы, количества, даты и статусы совпадают после утверждённых преобразований.
Обязательства: открытые заказы, резервы, неоплаченные суммы и незавершённые операции доступны для продолжения.
Поведение: пользователь выполняет следующий шаг по перенесённому объекту и получает правильный результат.
Количество строк может совпадать при переставленных ссылках. Общая денежная сумма может совпасть, даже если две ошибки взаимно компенсировались. Поэтому нужны разрезы по объектам, периодам, подразделениям и валютам.
Пример контрольной сверки
В учебном наборе 120 открытых заказов на 4 800 000 рублей. По ним отражено исполнение на 1 800 000 рублей, оставшееся обязательство — 3 000 000 рублей. Это условные суммы в одной валюте и одинаковой трактовке налогов.
После загрузки система показывает те же 120 заказов и общий итог 4 800 000. Однако по подразделению А остаток завышен на 50 000, а по подразделению Б занижен на столько же. Общая сумма не выявляет ошибку связи.
Поэтому сверка включает общий итог, итоги по подразделениям и выборочную либо полную проверку значимых объектов по принятому плану. Для критичных открытых обязательств выборка может быть недостаточной: способ проверки согласует владелец риска.
Если из 10 000 строк десять отклонены, показатель 99,9% сам по себе не даёт разрешения на запуск. Среди десяти может находиться единственный заказ, который нужно исполнить утром.
Подготовьте окно переключения
Для каждой операции назначьте исполнителя, ожидаемую длительность, результат и условие перехода дальше. Определите момент остановки записи в старую систему и способ учёта обращений, поступивших во время окна.
Последовательность может включать:
- подтверждение готовности пользователей и поддержки;
- прекращение изменений в источнике по согласованному порядку;
- фиксацию контрольного состояния и резервной копии;
- перенос последних изменений;
- итоговую сверку;
- пробное выполнение критичных сценариев;
- решение о разрешении записи в новой системе;
- уведомление участников о начале работы.
Простого объявления «не пользуйтесь старой системой» недостаточно, если остаются фоновые интеграции и автоматические задания. Их поведение тоже входит в план.
Сроки и допустимый перерыв выбирают для конкретного процесса. Пробная миграция должна подтвердить, что операции помещаются в согласованное окно с предусмотренным резервом.
Возврат после первых новых операций
До открытия записи возврат часто проще: старая система остаётся источником актуального состояния. После первых операций в новой системе это уже не так.
AWS в руководстве по переключению отдельно обращает внимание на подготовку возврата и изменение актуальности старого контура. Практический вывод: план должен объяснять судьбу данных, созданных после переключения.
Если в новой системе зарегистрировали семь заказов и две отгрузки, просто открыть старую означает потерять их в рабочем учёте. Нужен проверенный способ обратного переноса либо согласованная процедура восстановления операций с контролем дублей.
Если обратное преобразование невозможно, нельзя обещать мгновенный откат. Может потребоваться остановка, сверка, ручной разбор или исправление новой системы. Этот риск раскрывают до запуска.
Шаблон решения о готовности
- Контрольная дата: на какой момент сопоставлены данные.
- Полнота: ожидаемые, загруженные и отклонённые объекты.
- Сверки: суммы, связи, остатки и результаты сценариев.
- Отклонения: влияние, ответственный, решение.
- Окно: подтверждённая длительность и ограничения.
- Возврат: условия, срок принятия решения, новые операции.
- Полномочия: кто разрешает запуск и кто останавливает переход.
- Поддержка: контакты, режим наблюдения, критерии завершения усиленного сопровождения.
Не удаляйте старую среду сразу после успешного входа пользователей. Срок сохранения, доступ и дальнейшее закрытие определяются отдельно. При этом не допускайте незаметной параллельной записи в два независимых источника.
Подготовить миграцию помогают разбор перехода с таблиц и требования к внутренней системе. Для обсуждения заказной разработки принесите один набор связанных объектов и ожидаемые контрольные итоги.
Зафиксируйте судьбу отклонённых записей
Реестр ошибок должен позволять продолжить разбор после окна миграции. Для каждой записи нужны исходный идентификатор, причина, владелец, решение и подтверждение повторной обработки. Нельзя просто перенести проблемные строки в отдельный файл и считать их исключёнными по умолчанию.
Различайте согласованное исключение истории и потерю текущего обязательства. Первое может быть частью плана, второе требует решения до начала работы. При ручном исправлении сохраняйте исходное значение и основание изменения.
Также проверьте повторный запуск загрузки после частичного сбоя. Он не должен бесконтрольно дублировать уже принятые объекты. Требуемое поведение зависит от механизма переноса, но его необходимо испытать заранее. Контрольный реестр загруженных идентификаторов и результатов помогает отделить завершённые операции от тех, которые требуется повторить, и делает восстановление проверяемым.