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

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

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

Что такое миграция данных?

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

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

Из этого складывается любая миграция:

• Извлечение — выгрузка из старой системы: файл CSV или Excel, копия базы, запросы к API.
• Преобразование — приведение форматов, склейка дублей, сопоставление справочников и статусов.
• Загрузка — запись в новую систему с сохранением связей между таблицами.
• Сверка — доказательство, что перенеслось всё, что должно было.

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

Какие данные переносить, а какие оставить в архиве?

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

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

Отдельный вопрос — персональные данные. Если в базе есть данные граждан России, их запись, хранение и обновление должны идти в базе на территории России: это требование ч. 5 ст. 18 закона 152-ФЗ «О персональных данных». Если перенос делает подрядчик, у него должен быть доступ по поручению оператора, оформленному договором (ч. 3 ст. 6 того же закона). Миграция — хороший момент не переносить то, что давно не нужно: устаревшие персональные данные проще удалить, чем потом объяснять, зачем они хранились.

Данные	В новую систему	В архив	На что смотреть
Клиенты и контрагенты	Активные и те, с кем была сделка за последние 2–3 года	Давно неактивные, без контактов	Согласия на рассылку и на обработку персональных данных
Заказы и сделки	Открытые полностью, закрытые — итоговыми суммами	Подробности закрытых заказов	Статусы старой системы нужно сопоставить с новыми
Товары и цены	Всё, что в продаже	Снятые с продажи	Артикулы и коды 1С — это ключи для обмена
Документы и вложения	Договоры действующих клиентов	Остальное с поиском по номеру	Объём файлов часто больше всей базы
История и комментарии	По открытым сделкам	Остальное одним файлом	Авторы и даты записей при переносе часто подменяются
Пароли пользователей	Хеши, если новая система их понимает	—	Иначе — сброс пароля и письмо со ссылкой

Как подготовить и почистить данные?

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

Таблица сопоставления — главный документ миграции. В ней по строке на каждое поле: где лежит в старой системе, куда идёт в новой, как преобразуется, что делать с пустыми и кривыми значениями. Отдельно — справочники: статусы заказов, типы клиентов, менеджеры, склады, единицы измерения. Если в старой системе статус «Ждёт оплаты (частично)», а в новой его нет, решение принимает заказчик, а не программист.

Что обычно приходится чистить:

• Форматы. Даты в трёх видах, телефоны с восьмёркой и без, суммы с пробелами как текст.
• Дубли. Один клиент заведён трижды разными менеджерами. Ключ для склейки — ИНН у компаний, телефон или почта у людей; совпадение только по имени проверяют вручную.
• Сироты. Заказы, у которых удалили клиента, и контакты без компании.
• Мусор в справочниках. «Москва», «г. Москва», «Мск» — три города вместо одного.
• Тестовые записи. «Иван Тест», заказ на 1 рубль — их надо найти и не переносить.

Ещё одно правило: в новой системе для каждой записи сохраняют её номер из старой. Это поле почти никто не видит, но без него невозможно догрузить изменения, исправить ошибку повторным прогоном или найти, откуда взялась странная запись. Если со старой системой связана 1С, сохраните и коды из 1С — по ним дальше пойдёт обмен (как он устроен — в статье «Как 1С обменивается данными с сайтом и CRM»).

Как идёт перенос по шагам?

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

1. Инвентаризация источников — список, владельцы, объёмы.
2. Таблица сопоставления полей и справочников, согласованная письменно.
3. Первый прогон на копии. Его цель — не результат, а список ошибок: какие строки не легли и почему.
4. Исправление правил или исходных данных. Иногда проще поправить 40 строк руками в старой системе, чем писать под них особую логику.
5. Второй прогон и проверка заказчиком. Сотрудники открывают новую систему и ищут своих клиентов и свои заказы.
6. Заморозка. Объявленное время, после которого в старой системе ничего не меняют.
7. Финальный прогон — всё или только изменения с прошлого раза, если система позволяет их отследить.
8. Сверка по таблице ниже и решение о переключении.

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

Сверка	Как делается	Что ловит
Количество	Число записей по каждой таблице: было, перенесено, отброшено с причиной	Потерянные строки, обрыв загрузки
Суммы	Сумма заказов и оплат по месяцам, остаток долга по клиентам	Сдвиг дат, потерю копеек, неверную валюту
Связи	У скольких заказов нет клиента, у скольких контактов нет компании	Сломанные ссылки между таблицами
Выборка вручную	20–30 записей, включая самые старые и самые «грязные», открыть в обеих системах рядом	Перепутанные поля, кодировку, обрезанный текст
Файлы	Число вложений и общий объём, открыть по одному файлу каждого типа	Битые ссылки на документы и фото

Как проверить, что ничего не потерялось?

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

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

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

Переход за один день или параллельная работа?

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

Как выбрать:

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

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

Старую систему не удаляйте сразу после переезда. Переведите её в режим только чтения или сохраните полную выгрузку с инструкцией, как её открыть. Первичные бухгалтерские документы организация хранит не менее пяти лет после отчётного года — это ч. 1 ст. 29 закона № 402-ФЗ, и если они жили только в старой программе, архив обязателен.

Что чаще всего теряется при переносе?

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

• Вложения. В выгрузке остаётся ссылка на файл, а сам файл лежит в хранилище старой системы. Через месяц подписка заканчивается, и ссылки ведут в никуда.
• Автор и дата. Все перенесённые комментарии становятся «созданы администратором сегодня», если не перенести эти поля явно.
• История статусов. Новая система видит только текущий статус заказа, а отчёт «сколько дней от заявки до оплаты» строился по истории.
• Пароли. Расшифровать их нельзя. Либо новая система принимает хеши старого формата, либо всем пользователям уходит письмо со ссылкой на смену пароля — это надо подготовить, иначе в первый день поддержка утонет в звонках.
• Адреса страниц. Для магазина и сайта старые адреса товаров должны вести на новые через перенаправления, иначе теряются позиции в поиске и ссылки из рекламы.
• Согласия и отписки. Если клиент отписался от рассылки в старой системе, а в новую перенесли только его адрес, он снова начнёт получать письма.

Пример из нашей практики: при запуске нового интернет-магазина AleksFurs каталог со старого сайта перенесли автоматически — 159 моделей и 523 фото в шести категориях, а 226 адресов старого сайта ведут на новые страницы. Перенос фото и адресов здесь занял не меньше внимания, чем сами товары.

Что подготовить заказчику?

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

• Полная выгрузка из каждого источника или доступ к API старой системы — на время работ.
• Список справочников и что в них правильно: статусы, менеджеры, склады.
• Решение по архиву: с какого года или по какому признаку записи не переносим.
• 10–20 «эталонных» клиентов и заказов, которые сотрудники знают наизусть, — для ручной проверки.
• Дата и время заморозки, согласованные с отделом продаж и бухгалтерией.
• Текст письма пользователям, если меняются пароли или адрес входа.

Когда миграция не нужна и какие ошибки встречаются?

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

Типичные ошибки:

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

Сколько стоит миграция данных?

Отдельной строки в прайсе у миграции нет: её считают после того, как посмотрели выгрузки. Когда перенос входит в запуск новой системы, его включают в смету проекта; когда нужна разовая связка двух систем по API — это задача тарифа интеграций от 32 000 ₽.

Ориентиры по прайсу: интернет-магазин — от 104 000 ₽, веб-приложение, кабинет или CRM на заказ — от 160 000 ₽. Перенос данных в смете таких проектов идёт отдельной строкой, и её объём определяют число источников, качество данных, наличие API у старой системы и файлов-вложений. Цену и срок фиксируем в договоре до старта; результат проходит приёмку — на неё у заказчика 5 рабочих дней, — а гарантия по договору составляет 30 календарных дней с даты акта. Если после переезда нужно сопровождение и доработки, есть поддержка от 7 900 ₽ в месяц. Как мы ведём такие проекты целиком, описано на странице заказной разработки.

Короткие ответы на частые вопросы

Сколько длится миграция данных?

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

Можно ли перенести пароли клиентов из старого сайта?

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

Нужно ли останавливать работу на время переноса?

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

Что делать со старой системой после переезда?

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

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

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

Услуги и кейсы по теме: заказная разработка · кейс AleksFurs · цены и сроки