План миграции данных — это документ на две-три страницы из семи разделов: перечень объектов переноса, правила преобразования, правила отбраковки, порядок и окно работ, сверка, откат, ответственные. Он пишется до того, как назначена дата переезда, и подписывается двумя людьми: инженером подрядчика и владельцем данных со стороны заказчика. Всё, чего в нём нет, будет придумано в ночь переноса уставшим человеком под давлением времени.
Главный раздел здесь не технический. Правила преобразования инженер напишет и без вас. А вот решение «эти 290 карточек в новую систему не едут» может принять только тот, кто отвечает за клиентскую базу, — и принять его надо в спокойный вторник, а не в субботу в половине двенадцатого ночи, когда прогон встал на строке 4 118 и все хотят домой.
Ниже — структура плана с дословными формулировками, которые можно скопировать в свой файл и подставить свои числа. Сквозной пример один на всю статью: сервисно-оптовая компания, 34 человека, переезжает с самописной базы и двух таблиц Excel на связку amoCRM и 1С:УНФ. В базе 5 800 карточек контрагентов, 19 400 сделок за четыре года, 2 200 позиций прайса. Механика самого переноса — прогоны, сопоставление полей, цена работ — разобрана отдельно в материале про миграцию данных при внедрении; здесь речь про документ, который этой механикой управляет.
Семь разделов, владелец каждого и срок готовности
У каждого раздела есть фамилия и дата. Раздел без владельца не заполняется никогда: все считают, что его пишет кто-то другой. Колонка «что бывает, если пропустить» — не про абстрактные риски, а про конкретные деньги и дни из проектов, где раздел действительно пропускали.
| Раздел | Кто заполняет | Когда готов | Что бывает, если пропустить |
|---|---|---|---|
| 1. Перечень объектов переноса | Инженер вместе с владельцем данных | До сметы на переезд | На третьей неделе всплывает таблица отгрузок, которую никто не считал: плюс 40 000–60 000 ₽ и неделя к сроку |
| 2. Правила преобразования | Инженер | До тестового прогона | Телефоны приезжают в трёх форматах, поиск клиента при входящем звонке не срабатывает; переделка и повторный прогон — 12 часов инженера, 36 000 ₽ |
| 3. Правила отбраковки | Владелец данных (руководитель отдела продаж) | До тестового прогона | Решение принимается в ночь переноса, наутро выясняется, что в мусор ушли живые карточки, и восстановление идёт вручную |
| 4. Порядок и окно работ | Руководитель проекта со стороны заказчика | За две недели до переезда | Сотрудники продолжают вводить заявки во время переноса; 60–90 записей существуют только в старой системе и теряются |
| 5. Сверка | Владелец данных | Форма — до переезда, заполнение — в день переезда | Расхождение находят через месяц по жалобе клиента, и к этому моменту в новой системе уже есть свои изменения — сверять не с чем |
| 6. Откат | Инженер | До переезда, время отката замерено на тесте | Решение об откате принимает в два часа ночи уставший человек, у которого нет ни копии, ни критерия |
| 7. Ответственные и судьба старой системы | Руководитель проекта | До переезда | Старую базу выключают через неделю, а в ней остались сканы договоров и переписка по трём незакрытым спорам |
Схема документа: вертикальная колонка из семи пронумерованных блоков — «Перечень объектов», «Правила преобразования», «Правила отбраковки», «Порядок и окно работ», «Сверка», «Откат», «Ответственные и старая система». Справа от каждого блока две узкие ячейки с подписями «владелец» и «срок». Блоки 3 и 5 выделены жирной рамкой и помечены «заполняет заказчик, не подрядчик». Внизу строка подписи: «инженер / владелец данных». Чертёжный стиль, подписи по-русски.
Раздел 1. Перечень объектов: строка на объект, а не «перенести всё»
Перечень — таблица, где каждая строка это один объект переноса с источником, приёмником, объёмом на входе и объёмом на выходе. Разница между двумя последними колонками и есть предмет разговора: именно она показывает, сколько данных вы осознанно оставляете позади. Формулировка «переносим клиентов, сделки и товары» перечнем не является — под ней прячутся четыре несогласованных решения.
| Объект | Источник | Приёмник | На входе | Едет |
|---|---|---|---|---|
| Карточки контрагентов | Самописная база, таблица «Клиенты 2022–2026» | amoCRM: контакты и компании | 5 800 | 5 190 |
| Сделки | Самописная база | amoCRM: сделки | 19 400 | 8 900 — все открытые и закрытые за 24 месяца |
| Номенклатура и прайс | Excel «Прайс_итог.xlsx» | 1С:УНФ, справочник номенклатуры | 2 200 | 2 060 |
| Остатки на складе | 1С:Бухгалтерия | 1С:УНФ | 1 940 строк | 1 940, на момент закрытия окна |
| Взаиморасчёты | 1С:Бухгалтерия | 1С:УНФ | 412 контрагентов с сальдо | 412 |
| Переписка с клиентами | Почтовые ящики отдела продаж | Не переносится | 61 000 писем | 0 — выгрузка в архив, ссылка в карточке |
| Счета, акты, сканы договоров | Сетевая папка | Файловое хранилище | 14 300 файлов | Файлы остаются на месте, в карточку кладётся ссылка |
Две последние строки в этой таблице — самые важные, хотя выглядят как отказ от работы. Переписка и сканы почти никогда не должны переезжать внутрь новой системы: они раздувают её, замедляют поиск и портят приёмку. Правильный ответ — оставить их там, где они лежат, и связать с карточкой ссылкой. Если по архиву нужен поиск, это отдельная задача и отдельный бюджет — она решается поиском по архиву документов, а не строчкой в плане переезда.
Разделы 2 и 3. Правила преобразования и правила отбраковки
Правила преобразования пишутся так, чтобы их можно было проверить, а не понять. «Привести телефоны к единому формату» — не правило: единый формат у каждого свой. Ниже четыре формулировки из сквозного примера, которые можно скопировать целиком и поменять только названия полей.
- «Телефон приводится к виду +7XXXXXXXXXX. Значения, из которых после очистки от знаков получилось не 11 цифр, кладутся в поле „Телефон, не разобран“ и в поиске по номеру не участвуют.»
- «Название компании переносится без кавычек и без организационно-правовой формы. ОПФ пишется в отдельное поле „Форма собственности“.»
- «Если у карточки нет ответственного менеджера, ответственным ставится руководитель отдела продаж. Распределять такие карточки по менеджерам во время переноса запрещено.»
- «Дата без времени считается 00:00 по московскому времени. Все даты в приёмнике хранятся в московском времени, часовой пояс источника фиксируется в комментарии к строке.»
Правила отбраковки — та часть, которую подрядчик не может написать за вас физически: он не знает, какие клиенты для вас живые. Здесь тоже нужны формулировки с числами, а не намерения. Пять правил из примера дают ровно те 610 карточек, которые не поедут: 240 групп дублей, 290 карточек без контактов и без сделок и 80 без движения четыре года.
- 1«Не переносятся карточки контрагентов, у которых одновременно пусты телефон и электронная почта и нет ни одной сделки за 24 месяца. Таких карточек 290. Они выгружаются отдельным файлом и хранятся 12 месяцев.»
- 2«Группа дублей склеивается автоматически, если совпадает ИНН либо совпадают нормализованный телефон и первые три слова названия. Оставшиеся 240 групп разбирает руководитель отдела продаж до десятого рабочего дня проекта. Неразобранные к этому сроку переносятся как есть, каждая карточка отдельной строкой, с меткой „разобрать“.»
- 3«Не переносятся сделки, закрытые более 24 месяцев назад: 10 500 записей. Они выгружаются в архивный файл, ссылка на который кладётся в карточку клиента.»
- 4«Не переносится номенклатура с признаком „снята с продажи“ и без движения более 24 месяцев: 140 позиций.»
- 5«Любое решение об отбраковке, не записанное в этот раздел, во время переноса не принимается. Спорная строка переносится как есть с меткой „разобрать“ и разбирается после запуска.»
Первые четыре правила описывают конкретную базу и у вас будут другими. Пятое универсально: оно запрещает принимать новые решения об удалении данных в момент переноса. Именно ночные решения «да ладно, это явно мусор» стоят потом дороже всего — потому что удалённое невозможно отличить от того, что не доехало из-за ошибки.
Карта потока слева направо. Слева три узла-источника: «Самописная база», «Excel: прайс», «1С:Бухгалтерия». В центре широкий блок «Правила отбраковки», из него вниз отводится ветка «не едет: 610 карточек — 240 дублей, 290 без контактов, 80 без движения» с пометкой «выгрузка, хранение 12 месяцев». Справа два узла-приёмника: «amoCRM — 5 190 карточек, 8 900 сделок» и «1С:УНФ — 2 060 позиций, 1 940 строк остатков». Отдельная нижняя ветка «Переписка и сканы — остаются на месте, ссылка в карточке». Чертёжный стиль, подписи по-русски.
Раздел 4. Тестовый перенос и окно работ
Правило простое: дата переезда назначается не раньше, чем закончился тестовый прогон на копии приёмника, у которого сошлись все контрольные срезы. До этого любая названная дата — пожелание. Тестовый прогон делается на полном объёме данных, а не на выборке: половина проблем вылезает именно на редких строках.
- 1Полный прогон на копии
Перенос идёт целиком, от начала до конца, без ручных правок в процессе. Любая правка руками во время прогона означает, что прогон не засчитан и повторяется заново.
- 2Замер времени
Секундомер включается в начале и выключается в конце. Боевое окно планируется как время тестового прогона, умноженное на 1,5 — запас уходит на то, чего на тесте не было: живая нагрузка, чужие блокировки, человеческая пауза на кофе.
- 3Сверка всех срезов на тестовых данных
Заполняется та же форма сверки, что будет заполняться в боевую ночь. Если форма заполняется в первый раз в день переезда, она заполняется плохо.
- 4Ручная проверка 30 карточек
Десять крупнейших контрагентов, десять случайных и десять из спорных групп дублей. Смотрит владелец данных, а не инженер: инженер не заметит, что менеджер в карточке не тот.
- 5Проверка отката с секундомером
Копия приёмника восстанавливается, старая система включается в режим записи. Полученное время попадает в раздел 6 как норматив. Непроверенный откат — это не план, а надежда.
- 6Показ пяти сотрудникам их собственных карточек
Пять менеджеров открывают в тестовой системе своих клиентов и говорят, что не так. Это находит вещи, которых нет ни в одном срезе: пропавшие комментарии, не тот этап сделки, слипшиеся адреса.
Окно работ описывается по часам и вывешивается людям заранее. Дословная формулировка для рассылки сотрудникам, которую можно скопировать: «С 18:00 пятницы до 9:00 понедельника ввод данных в обе системы закрыт. Заявки, поступившие в это время, записываются в бумажный журнал у дежурного менеджера и вносятся в новую систему в понедельник до 11:00. Ответственный за журнал — старший менеджер смены. Данные, введённые в старую систему после 18:00 пятницы, в новую не попадут.»
Горизонтальная лента времени от пятницы до понедельника с отметками: «Пт 18:00 — ввод закрыт, бумажный журнал», «Пт 18:30 — сняты копии источника и приёмника», «Пт 19:00–23:00 — перенос», «Сб 09:00–14:00 — сверка шести срезов и 30 карточек», «Сб 21:00 — точка решения: принять или откатить», «Вс — резервный день», «Пн 09:00 — старт работы, дежурство инженера и внесение бумажного журнала до 11:00». Отметка «Сб 21:00» выделена. Чертёжный стиль, подписи по-русски.
Раздел 5. Сверка: шесть срезов и 30 карточек
Сверка — это числа, а не впечатление. Формулировка «данные готовы» в акте не значит ничего; формулировка «расхождение по трём денежным срезам не превысило 0,5 %» значит ровно то, что написано. Форма сверки готовится заранее и заполняется дважды: на тестовом прогоне и в боевую ночь.
| Срез | Как считается | Допустимое расхождение |
|---|---|---|
| Число карточек контрагентов | Количество в источнике после отбраковки против количества в приёмнике | 0 |
| Число сделок | Количество отобранных к переносу против количества в приёмнике | 0 |
| Сумма закрытых сделок за 24 месяца | Сумма поля в обеих системах, один и тот же период | не более 0,5 % |
| Сальдо взаиморасчётов по 412 контрагентам | Итоговая сумма и число контрагентов с ненулевым сальдо | не более 0,5 % |
| Остатки на складе | Сумма количеств по 1 940 строкам | 0 |
| Заполненность обязательных полей | Доля карточек, где заполнены ответственный, телефон или почта, тип клиента | не ниже, чем было в источнике |
| 30 карточек вручную | 10 крупнейших, 10 случайных, 10 из спорных групп дублей | 0 ошибок в обязательных полях |
Критерий приёмки формулируется одной фразой: «Перенос считается принятым, если по всем шести срезам расхождение укладывается в норматив таблицы, а из 30 карточек ручной проверки ни в одной нет ошибки в обязательных полях. При невыполнении любого условия применяется раздел 6.» Отдельное расхождение в 0,5 % по деньгам не означает, что можно расслабиться: разница обязана объясняться словами — округление, курс, исключённые тестовые сделки, — иначе это не допуск, а необъяснённая пропажа.
Сравнительная форма в две колонки «Источник» и «Приёмник» с шестью строками срезов: контрагенты 5 190 / 5 190, сделки 8 900 / 8 900, сумма закрытых сделок с пометкой «допуск 0,5 %», сальдо по 412 контрагентам с той же пометкой, остатки 1 940 строк с пометкой «допуск 0», заполненность обязательных полей. Внизу отдельный блок «Ручная проверка: 30 карточек — 10 крупнейших, 10 случайных, 10 спорных, допуск 0 ошибок». Справа поле подписи «владелец данных». Чертёжный стиль, подписи по-русски.
Разделы 6 и 7. Откат, ответственные и судьба старой системы
Откат пишется заранее, потому что в момент, когда он нужен, писать его некому. Раздел состоит из трёх формулировок: критерий, кто решает, что именно делается. Все три должны помещаться в один абзац, который прочитает вслух дежурный.
- «Перенос откатывается, если к 21:00 субботы не сошёлся хотя бы один срез из шести и причина расхождения не найдена в течение часа.»
- «Решение об откате принимает руководитель проекта со стороны заказчика единолично. Совещание для этого не собирается.»
- «Откат — это восстановление копии приёмника, снятой до начала переноса, и включение старой системы в режим записи. Норматив времени отката — 90 минут, он замерен на тестовом прогоне. Следующая попытка переноса назначается не раньше чем через неделю.»
Если в плане написано «в случае критических проблем возможен откат», отката не будет: в три часа ночи никто не признает свои проблемы критическими, потому что до конца всегда кажется полчаса. Работает только время в расписании — конкретная отметка, к которой либо сошлось, либо нет.
Седьмой раздел закрывает вопрос, который обычно откладывают: сколько живёт старая система и кто в неё ходит. Ответ «пока не удалим» приводит к тому, что через полгода половина отдела продолжает работать в старой базе, а данные расходятся в двух местах. Ответ «выключим через неделю» приводит к тому, что через месяц никто не может найти скан договора по спору на 400 000 ₽.
Рабочая формулировка: «Старая система переводится в режим только чтения в день переезда. Она остаётся доступной 12 месяцев; право чтения — у трёх сотрудников по списку: руководитель отдела продаж, главный бухгалтер, системный администратор. Ввод новых данных в неё технически закрыт. Через 12 месяцев система выключается по акту, её резервная копия и выгрузка в CSV хранятся ещё три года в соответствии со сроками, указанными в согласиях на обработку персональных данных.» Последняя часть не формальность: персональные данные клиентов нельзя хранить бессрочно «на всякий случай», и срок хранения архива должен соответствовать тому, что вы написали в собственной политике обработки данных.
Сотрудник заказчика, который отвечает за содержание базы, а не за её работоспособность. Обычно это руководитель отдела продаж, главный бухгалтер или начальник склада. Именно он подписывает разделы про отбраковку и сверку и принимает перенос. Системный администратор владельцем данных не является: он отвечает за то, что база доступна, а не за то, что в ней написано.
Сколько стоит написать план и сколько стоит его не писать
План — это часы людей, и часть этих часов принадлежит заказчику. Расчёт ниже сделан по канонным для журнала полным ставкам часа сотрудника: инженер-подрядчик 3 000 ₽/час, руководитель подразделения 1 800 ₽/час, менеджер по продажам 900 ₽/час, бухгалтер 844 ₽/час.
Обратите внимание, где сидят деньги в нижней половине расчёта: не в инженере, а в собственных сотрудниках, которые два дня работают вслепую. Это общее свойство неудачных переездов — подрядчик переделывает за свои часы, а платит компания рабочим временем отдела. Тот же принцип действует в чек-листе готовности к запуску: дешевле остановиться до включения, чем чинить после.
Когда план миграции — лишняя бюрократия
Документ из семи разделов нужен не всем. Если объектов переноса один-два, источник один и данных немного, план превращается в ритуал, который отнимает больше времени, чем сам перенос. Простая проверка: посчитайте ручной ввод. 500 карточек по четыре минуты — это 33 часа, то есть около 30 000 ₽ по ставке менеджера. Дешевле, чем 59 832 ₽ на план плюс сам перенос, и надёжнее: человек, вводящий карточку руками, попутно чистит её.
- Меньше 500 карточек из одного источника. Ввод руками силами двух сотрудников за неделю. План заменяется одной страницей: что вводим, кто вводит, к какому числу.
- Переезд внутри одного вендора штатным конвертером — например, между конфигурациями 1С. Правила преобразования уже написаны производителем, и ваша работа сводится к отбраковке и сверке.
- Компания до десяти человек, где владелец данных — сам директор. Согласовывать не с кем, решение об отбраковке принимается за пятнадцать минут. Достаточно двух разделов из семи.
- Тестовый или демонстрационный контур, который не жалко пересобрать заново. Здесь план вреден: он создаёт иллюзию, что данные в контуре чего-то стоят.
Но два раздела остаются обязательными даже в самом маленьком проекте: правила отбраковки и окно с заморозкой ввода. Первый защищает от ночных решений, второй — от записей, которые существуют только в старой системе. Всё остальное можно ужать до абзаца. А если переезд связан не с одной системой, а со связкой из нескольких, отдельно понадобится документ требований к интеграции — план миграции его не заменяет и не должен.
