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

Стратегия: подменять, а не переписывать целиком

Полная переписка «с нуля» к запуску в один день почти всегда срывается по срокам и бюджету. Работающий приём – постепенное вытеснение. Перед старым монолитом ставим прослойку-маршрутизатор. Сначала весь трафик идёт в legacy. Затем по одному модулю – справочники, потом отчёты, потом расчёты – переносим логику в новый код, а маршрутизатор перенаправляет на него запросы. Старый модуль остаётся как резерв. Если новый даёт сбой, переключение обратно занимает минуты, а не сутки восстановления из бэкапа.

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

Данные: двойная запись и сверка

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

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

Риски, доступ и сдача

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

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

Вывод

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