Миграция со старой системы — FAQ

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

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

client_name → «Название клиента»
manager_id → «Ответственный менеджер»
order_status → «Статус заказа»

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

В кейсе портала услуг новые модули добавляли поверх существующей базы после стабилизации legacy-кода. Слой сопоставления полей при обмене с учётной системой разобран на странице интеграции Laravel с 1С.

Да. Старые заказы не обязательно переносить только в виде итоговой суммы и статуса.

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

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

Можно разделить данные: последние 2–3 года перенести полностью, более старые заказы оставить в архиве, редкие исторические данные сделать доступными только для просмотра. Журнал версий заказа описан в FAQ про заказы и заявки; пример полной истории в B2B-контуре — в кейсе B2B-портала.

Пользователи и клиенты обычно переносятся отдельно, потому что это разные сущности.

Для клиентов можно сохранить: название компании, контактных лиц, телефоны, email, реквизиты, адреса, договоры, менеджера, персональные условия, историю заказов. Для сотрудников — имя, email, подразделение, должность, роль, доступные организации, права доступа.

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

Также необходимо проверить, чтобы после переноса пользователи не получили лишние права доступа. Карточка клиента и роли сотрудников — в FAQ про CRM и работу менеджеров; перенос клиентской базы в рабочий контур — в кейсе портала услуг.

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

До очистки: ООО «Пример», ООО Пример, Пример ООО, OOO «Пример»
После очистки: ООО «Пример»

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

Сверка контрольных показателей после запуска — часть контура из FAQ про контроль и аналитику. Один из симптомов «грязных» данных — дубли клиентов в разных таблицах, описанный в интервью про Excel и Telegram.

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

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

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

Критерии «ремонтировать или переписывать» — в интервью про legacy Laravel. Пример поэтапного добавления модулей поверх существующего кода — в кейсе портала услуг.

Не всегда. В некоторых проектах старую и новую системы можно использовать параллельно в течение переходного периода.

Например, старые заказы завершаются в прежней CRM, а новые заказы создаются уже в новой системе. Другой вариант — временная синхронизация между двумя системами.

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

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

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

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

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

Журнал обмена и повторная отправка после ошибки — в архитектуре интеграции Laravel + 1С. Контрольные показатели и сверка после запуска — в FAQ про контроль и аналитику.

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

Менеджеру не обязательно знать все возможности системы. Ему важно понимать: как создать клиента, принять заявку, оформить заказ, изменить статус, отправить документ, найти предыдущий заказ, что делать при ошибке.

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

После запуска желательно собирать вопросы сотрудников. Если один и тот же вопрос возникает регулярно, проблема может быть не в обучении, а в интерфейсе. Типовые сценарии менеджера — в FAQ про заказы и заявки и FAQ про CRM и работу менеджеров.