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

Содержание:

Определить состав переноса и доступный архив

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

В руководстве по миграции Dynamics 365 Microsoft отдельно рассматривает настройки системы, справочники и открытые операции — в том числе заказы, остатки и незакрытые балансы. Для приёмки полезно такое же разделение: нужные записи могут загрузиться, но для работы с ними ещё потребуются согласованные настройки, например валюты и единицы учёта. Сам Dynamics 365 для этого подхода не обязателен.

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

Архив тоже нужно принять. Попросите будущего пользователя найти в нём старый документ и открыть связанный файл под своей учётной записью. Определите, кто отвечает за доступ, резервные копии и согласованный срок хранения. Если архивом остаётся старая программа, заранее выясните условия её дальнейшего использования. Решение не загружать историю в новую систему не должно означать, что после отключения старой программы история станет недоступна.

До начала работ исполнитель должен показать, что выбранный способ экспорта и импорта поддерживает именно этот состав. Сначала имеет смысл проверить штатные средства выбранной системы: возможно, их достаточно для всего переноса.

Согласовать соответствия и сохранить связи

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

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

Попросите исполнителя показать соответствия на нескольких записях до массовой загрузки. Как определить, что старая и новая карточки относятся к одному клиенту? Где сохранится старый номер заказа? Что делать с пустым обязательным полем или значением, которому не нашлось соответствия? Ответы нужно записать так, чтобы сотрудник, принимающий данные, мог проверить их без чтения программы переноса.

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

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

Неизвестное значение лучше отправить на разбор, чем молча заменить удобным значением по умолчанию. Кто принимает решение о такой замене, тоже стоит согласовать заранее. Исполнитель отвечает за реализацию утверждённого правила; смысл статуса или допустимость объединения клиентов подтверждает сотрудник компании, который знает процесс.

Провести пробный перенос и проверить работу

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

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

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

В документации AWS DMS описана автоматическая проверка соответствующих строк источника и назначения. Сервис различает несовпавшие записи, ожидающие проверки и записи, которые сравнить не удалось. Это полезное различие для отчёта любого исполнителя: отсутствие найденных ошибок не объясняет, всё ли было проверено. У самой проверки DMS есть ограничения: нужен первичный ключ или уникальный индекс, чтобы однозначно различать записи в таблице; выполнение этого требования проверяет исполнитель. Постоянно меняющиеся строки могут не проверяться, а сравнение создаёт дополнительную нагрузку. Документация описывает конкретный сервис, не универсальную возможность любого импорта.

Для своей системы согласуйте несколько видов доказательств:

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

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

Универсального допустимого процента расхождений здесь нет. Для каждого найденного отклонения запишите затронутые записи, последствия для работы, решение и ответственного. Необъяснённая разница в остатках и согласованное отсутствие ненужной архивной заметки требуют разных решений. После исправления правил повторите затронутые сверки и рабочие сценарии; перед запуском проверьте окончательную загрузку. Результаты пробы относятся к той версии данных и правил, на которой её провели.

Учесть изменения к моменту переключения

Между пробой и запуском старая система может продолжать работать. В условном примере заказ успеют дополнительно отгрузить, изменить или отменить. Хороший результат тестовой загрузки ничего не говорит о том, попали ли эти изменения в окончательный перенос.

Назначьте момент, на который принимаются данные, и определите, где до него регистрируются операции. Один вариант — согласованная остановка ввода с окончательной выгрузкой. Другой — первоначальная загрузка и последующий перенос изменений до установленной границы. Возможность второго варианта должен подтвердить исполнитель для конкретных систем. Нужно учесть новые записи, исправления, удаления и смену статусов; выгрузки только недавно созданных карточек может не хватить.

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

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

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

Разрешить запуск и определить условия возврата

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

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

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

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

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

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

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

Проверить готовый импорт до заказа разработки

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

Если готовый способ закрывает согласованный состав и проверки, отдельная разработка может не понадобиться. Если остаются ограничения, их стоит назвать точно: не переносится история, теряются вложения, невозможно сопоставить карточки или неудобно разбирать исключения. Для этого остатка сравниваются настройка, другой готовый инструмент, доработка и ручной перенос ограниченного объёма. Учитываются время сотрудников, повторяемость проверки и дальнейшая поддержка.

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

Если переход уже запланирован, а способ проверить данные и продолжить незавершённую работу пока не определён, стоит разобрать это до основной загрузки. Обсудить задачу.

Источники

Источники прочитаны 16 октября 2026 года. Они описывают конкретные продукты; предложенный порядок приёмки нужно адаптировать к своей системе. Примеры с заказом условные, миграция на клиентских данных для этой статьи не проводилась.