Как перейти со старой системы на новую без остановки работы
Замена корпоративной системы редко сводится к простой последовательности:
В реальном бизнесе старая система продолжает работать до самого момента перехода. В ней создаются заказы, меняются остатки, появляются новые документы, сотрудники редактируют карточки клиентов, оборудование передаёт данные, внешние системы продолжают обмениваться информацией.
Поэтому главная проблема миграции — не только перенести данные.
Нужно сделать так, чтобы в момент перехода:
И всё это желательно сделать без остановки бизнеса.
Почему нельзя просто перенести базу целиком
Представим обычную ситуацию.
Старую систему необходимо заменить на новую.
В понедельник утром была выполнена выгрузка данных:
10:00
1 000 000 записей
│
▼
МИГРАЦИЯ
│
▼
НОВАЯ СИСТЕМА
10:00
1 000 000 записей
На первый взгляд всё хорошо.
Но старая система продолжает работать.
К 16:00 в ней появились:
новые заказы;
новые клиенты;
изменённые цены;
проведённые документы;
новые остатки;
изменения статусов.
Теперь данные выглядят так:
Если просто переключить пользователей на новую систему, часть данных останется в старой.
Поэтому миграция — это не одно копирование.
Это управляемый процесс перехода между двумя работающими контурами.
Правильная миграция начинается задолго до переключения
Безопасный переход обычно строится примерно так:
Не каждый проект требует одинакового количества этапов.
Но принцип один: переход готовится заранее, а не начинается в день отключения старой системы.
Сначала нужно понять, что именно находится в старой системе
Одна из самых опасных ошибок — считать, что структура старой системы очевидна.
В старой базе могут находиться:
Поэтому перед миграцией необходимо определить:
│
├── Клиенты
├── Контрагенты
├── Товары
├── Заказы
├── Документы
├── Остатки
├── Пользователи
├── Справочники
├── История
└── Технические данные
И для каждой категории ответить:
Попытка перенести абсолютно всё иногда создаёт новую проблему — новая система получает весь старый технический и исторический багаж.
Структуры старой и новой системы почти никогда не совпадают
Это один из центральных моментов миграции.
Например, в старой системе:
├── ID
├── NAME
├── PHONE
└── ADDRESS
├── CUSTOMER_ID
├── LEGAL_NAME
├── CONTACTS
│ ├── PHONE
└── ADDRESSES
Нельзя просто сказать:
«Перенесём таблицу клиентов».
Нужно определить соответствие:
И отдельно определить, что делать с полями, для которых нет прямого соответствия.
Миграция — это преобразование, а не копирование
Очень часто данные приходится менять во время переноса.
Например:
Статус = 2
Статус = 3
NEW
IN_PROGRESS
COMPLETED
Тип = Юридическое лицо
Поэтому перед миграцией формируется правило преобразования данных.
Для каждого важного объекта должно быть понятно:
Особенно опасны идентификаторы
Если старая система присвоила клиенту ID 15273, это ещё не означает, что в новой системе он должен иметь тот же ID.
При миграции может возникнуть таблица соответствий:
Такие соответствия особенно важны, если другие системы продолжают ссылаться на старые идентификаторы.
Иначе можно получить ситуацию, когда заказ существует, клиент существует, но связь между ними потеряна.
Первая миграция должна быть тестовой
Не стоит впервые выполнять настоящий перенос непосредственно перед запуском.
Сначала выполняется тестовая миграция.
После неё проверяется не только количество строк.
Проверяется смысл данных.
Например:
Количество записей — лишь один из показателей.
Можно перенести миллион записей и получить неправильную систему.
Проверять нужно контрольными показателями
Для критичных данных полезно заранее определить контрольные значения.
Например:
Но даже совпадение этих показателей не гарантирует полной корректности.
Поэтому проверяются ещё и выборочные записи, связи, документы и бизнес-сценарии.
Следующий уровень — параллельная работа
Для крупных систем часто используется период, когда старая и новая системы существуют одновременно.
Например:
Пользователи постепенно переходят на новую систему, а данные продолжают контролируемо синхронизироваться.
This позволяет обнаружить проблемы до полного отказа от старой системы.
Но параллельная работа сама по себе не решает проблему.
Нужно заранее определить, какая система является источником истины для каждой категории данных.
Нельзя бесконтрольно менять одни и те же данные в двух системах
Представим:
Цена = 1 000 ₽
Цена = 1 050 ₽
Какая цена правильная?
Если обе системы позволяют одновременно изменять одни и те же данные без правил синхронизации, конфликт неизбежен.
Поэтому необходимо определить:
Это уже не просто задача переноса.
Это архитектура переходного периода.
Что делать с новыми данными, появившимися после первой миграции
Допустим, основная миграция выполнена во вторник.
После неё старая система продолжила работать.
Перед окончательным переключением их нельзя просто проигнорировать.
Обычно используется механизм дельта-миграции:
В итоге в новую систему попадает не только исходный снимок, но и изменения, произошедшие после него.
Финальное переключение — отдельная операция
Даже если почти вся работа уже выполнена, момент перехода требует отдельного плана.
Обычно перед ним фиксируется состояние:
В этот момент важно не просто сказать:
Нужно понимать:
Самый важный документ перед переключением — план перехода
Для серьёзной системы полезно иметь отдельный пошаговый план.
Например:
Конкретное время зависит от бизнеса.
Главное — чтобы переход был сценарием, а не импровизацией.
А что если новая система после запуска ведёт себя неправильно?
Нужно предусмотреть это до переключения, а не после.
Поэтому заранее определяется rollback-сценарий.
Но здесь есть важная тонкость.
Если после перехода в новой системе уже появились новые данные, простой «откат» может быть невозможен.
Поэтому rollback должен учитывать:
Иногда безопаснее не возвращаться назад, а исправить проблему уже в новом контуре.
Именно поэтому решение о возможности отката должно приниматься до миграции.
Пользователей тоже необходимо переводить
Технически успешная миграция может закончиться организационным провалом.
Новая система запущена.
Данные на месте.
Интеграции работают.
Но сотрудники продолжают:
использовать старую систему;
создавать документы в неправильном месте;
обходить новые процессы;
работать по старым инструкциям.
Поэтому переход пользователей — тоже часть миграции.
Для разных ролей необходимо понимать:
Особенно это важно для складов, производства, продаж и других подразделений, где система является частью ежедневной операции.
Нельзя забывать про внешние интеграции
Старая система редко живёт отдельно.
С ней могут работать:
При переходе нужно понимать, когда каждая система начинает обращаться к новой системе вместо старой.
Например:
1С ─────────► Старая система
WMS ────────► Старая система
1С ─────────► Новая система
WMS ────────► Новая система
Если поменять только основной контур и забыть одну интеграцию, старая система может продолжить получать новые данные.
А бизнес получит два разных состояния реальности.
Как понять, что миграция действительно завершена
Фраза «данные перенесли» недостаточна.
Завершение миграции должно подтверждаться набором проверок.
И отдельно должны существовать критерии, после которых старая система действительно может быть выведена из эксплуатации.
Самая опасная ошибка — планировать миграцию как один вечер
Если вся стратегия выглядит так:
— это не стратегия миграции.
Это ставка на то, что всё получится с первого раза.
Надёжный подход выглядит иначе:
Чем больше цена простоя и ошибки, тем меньше смысла делать переход «одним большим прыжком».
Миграция — это управляемое изменение работающего бизнеса
Хороший переход со старой системы на новую не означает, что старая система внезапно перестала существовать, а новая появилась вместо неё.
Правильнее представить процесс как постепенное изменение контура:
При таком подходе миграция становится не разовой операцией, а управляемым инженерным процессом с контрольными точками.
Именно это позволяет заменить даже критичную корпоративную систему без необходимости останавливать бизнес на неопределённый срок.
Главная цель миграции — не просто получить новую систему.
Главная цель — сделать так, чтобы бизнес продолжал работать, пока меняется система, на которой этот бизнес работает.
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870