Миграция программного обеспечения — это управляемая замена “как работает сейчас” на “как будет работать завтра” (с данными, интеграциями и пользователями), чтобы снизить риски зависимости от вендора и уложиться в требования бизнеса; по факту это проект про деньги, сроки и контроль, а не про «переустановить софт».

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

Если вы меняете профессию и смотрите на IT, миграции — отличный «вход в реальную работу», потому что тут нужны базовые навыки анализа, коммуникации и аккуратной инженерии. Если вы джун/мидл, миграционные проекты быстро прокачивают понимание архитектуры, интеграций и процессов эксплуатации. И да, на рынке такие задачи обычно не заканчиваются: бизнес регулярно переезжает — с SAP на 1С, с Exchange на российские почтовые платформы, с Jira на отечественные аналоги, с VMware на альтернативную виртуализацию, и так по кругу.

Почему миграция — это бизнес-задача, а не “айтишники разберутся”

1) Декомпозиция цели: что именно вы мигрируете

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

Обоснование: бизнес редко страдает из‑за отсутствия “кнопок”. Он страдает из‑за потери данных, простоя процессов и обрыва обменов (например, CRM перестала отдавать лиды в колл-центр, бухгалтерия — закрывать месяц, склад — печатать этикетки).

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

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

• Функциональная миграция: заменяем систему/модули (например, Service Desk, документооборот, почта).
• Миграция данных: справочники, транзакции, вложения, история, журналы.
• Интеграции: API, файлы, шины (ESB), обмены через очереди, регламентные выгрузки.

2) “Отечественное ПО” — это не один продукт, а набор компромиссов

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

Обоснование: при замене привычного стека вы платите не только лицензией: меняется модель администрирования, SLA (уровень сервиса), обновления, совместимость с железом/ОС, требования к квалификации команды.

Практический вывод: оценивайте TCO (total cost of ownership — полная стоимость владения) на 2–3 года, а не “сколько стоит лицензия”.

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

3) Скрытая цена миграции: где “съедаются” бюджет и сроки

Тезис: миграция почти всегда дороже, чем кажется на этапе «давайте поменяем софт».

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

Практический вывод: закладывайте в план отдельную фазу “гиперкар” (hypercare) — период усиленной поддержки 2–6 недель после запуска, когда вы ловите реальные пользовательские сценарии.

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

1. Предпроектное обследование: 2–6 недель даже для “простых” систем.
2. Конвертация данных: маппинг (соответствие полей), очистка, прогон тестовых загрузок.
3. Интеграции: переписывание коннекторов, согласование форматов, изменение регламентов.
4. Тестирование: функциональное + нагрузочное + безопасность.
5. Обучение и коммуникации: инструкции, роли, поддержка первого уровня.
6. Стабилизация: исправления в реальном контуре, настройка мониторинга.

Чек-лист: как мигрировать софт без героизма по ночам

Минимальный план миграции (то, что реально работает)

• Инвентаризация: список систем, модулей, интеграций, отчётов, пользователей, прав.
• Критичность: какие процессы нельзя останавливать (и на сколько минут можно).
• Целевая архитектура: где будет жить система, как будет бэкапиться, чем мониторить.
• Стратегия переноса данных: “всё/остатки/по периодам”, правила качества данных.
• План тестирования: тест-кейсы на ключевые сценарии + критерии “готово”.
• Cutover-план: сценарий переключения (когда отключаем старое, когда включаем новое, кто решает “откат”).
• План отката: как вернуться назад, если что-то пошло не так.
• Hypercare: кто на связи, как фиксируем инциденты, сроки исправлений.

Оценка рисков: простая матрица, которую понимают и бизнес, и IT

Тезис: риски миграции лучше считать заранее, чем потом обсуждать “почему все не предупредили”.

Два кейса из практики: один “в плюс”, второй — для профилактики иллюзий

Кейс 1: успешная миграция с “параллельным контуром”

Компания переносила сервис-деск и базу знаний на другой продукт. Сделали пилот на одном департаменте, подняли параллельный контур, 3 недели гоняли реальные заявки “вживую”, потом переключили всех за выходные. Ключевое решение: не тащили в новую систему весь мусор — перенесли справочники, активные заявки и базу знаний за последний год. Итог: пользователи поругались первые два дня и успокоились, потому что ответы на “где кнопка” были готовы, а метрики SLA не рухнули.

Кейс 2: провал из серии “успеем до конца месяца”

В другой организации решили мигрировать документооборот, “потому что лицензии и всё такое”. Интеграции с почтой и согласованиями не инвентаризировали, тестирование сделали “на трёх документах”, cutover-плана не было, откат — тоже “зачем”. В день запуска часть маршрутов согласования сломалась, документы зависли, начались ручные пересылки и параллельный хаос. Самое дорогого: потом пришлось делать второй проект — уже нормальный — и платить два раза за одно и то же знание.

Если хотите больше таких разборов без маркетинговой пудры — похожие статьи лежат на https://itokno.ru, там много прикладной аналитики про реальные IT-проекты и карьерные траектории.

Экспертный вердикт и инструмент

Миграция программного обеспечения окупается не “патриотизмом в лицензиях”, а снижением регуляторных и вендорных рисков, повышением управляемости и предсказуемости эксплуатации. Но окупаемость появляется только если вы заранее считаете стоимость простоя, трудозатраты на интеграции и цену ошибки в данных.

7 вопросов, которые нужно задать перед тем, как мигрировать (и перед тем, как выбрать отечественное ПО)

1. Какой процесс бизнес считает критичным и какой допустимый простой (RTO) и потерю данных (RPO) он готов принять?
2. Какие данные обязательно сохранить с историей, а какие можно оставить в архиве “только читать”?
3. Сколько интеграций у текущей системы и кто реально их поддерживает?
4. Есть ли у целевого решения нормальные механизмы экспорта/импорта, API и журналирования?
5. Как будет выглядеть план отката, если запуск пошёл не по плану?
6. Кто владелец миграции со стороны бизнеса (не IT), кто принимает результат?
7. Какая будет модель поддержки после запуска: 1 линия, 2 линия, разработчики, SLA?

Частые вопросы