Я готовлю миграцию данных к первому рабочему дню, а не к последнему экспорту

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

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

Первый день даёт более честный критерий

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

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

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

Это не универсальный набор. У производственной компании будет другой первый день, у SaaS — третий. Смысл один: проверять не базу вообще, а действия, от которых зависит продолжение работы.

Почему «все записи на месте» мало о чём говорит

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

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

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

Три списка вместо одного

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

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

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

Сверка должна отвечать на вопросы бизнеса

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

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

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

Репетиция лучше большого сюрприза

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

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

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

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

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

Один принимает и сортирует проблемы. Другой подтверждает, как должен работать бизнес-сценарий. Третий разбирает техническую причину. Четвёртый сообщает команде понятный статус. Когда эти роли не определены, одно простое расхождение быстро превращается в цепочку сообщений «кто-нибудь знает, что делать?».

Заранее полезно обозначить и границу критичности. Ошибка оформления одного редкого старого документа может попасть в план исправлений. Невозможность принять новый заказ или провести отгрузку требует немедленного решения. Такой порядок помогает не смешивать важное с шумом в первые часы.

Переключение — это не только дата

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

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

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

Не переносите старые привычки незаметно

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

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

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

Миграция считается успешной утром

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

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

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

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