Привет, на связи Дмитрий Бессольцев, руководитель ALP ITSM. Уже 30 лет мы строим и поддерживаем ИТ-инфраструктуру для крупного и среднего бизнеса. Мы видели сотни миграций — и идеальных, плановых, и «пожарных», когда счет шел на часы. Этот кейс как раз из вторых.

Для тех, кто вечно занят — резюме статьи за 1 минуту:

• Миграция — это не Ctrl+C / Ctrl+V. Перенос серверов «как есть» переносит в облако и все старые проблемы архитектуры, которые на новой площадке могут просто не заработать.
• Серые зоны ответственности — главная угроза. Когда провайдер отвечает только за «железо», а клиент думает, что за «работу 1С», в момент сбоя бизнес остается один на один с проблемой.
• Экономия на Project Manager (PM) обходится дорого. Без единого центра управления миграция превращается в хаос из четырех несогласованных сторон.
• Аудит дешевле простоя. «Пожарный» переезд без предварительной диагностики лицензий и сетевых связей гарантированно приводит к остановке процессов.
• Чек-лист безопасности. В конце — 6 вопросов, которые собственник должен задать ИТ-директору перед стартом любого переезда.

«Мы переедем по плану»: когда карта не совпадает с местностью

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

В проекте участвовали четыре стороны:

• Клиент, которому нужно сохранить производство и продажи.
• Текущий хостер (старая площадка), откуда нужно уйти.
• Новый облачный провайдер, дающий мощности.
• Наша команда как сервисный партнер.

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

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

Что говорит рынок: миграция — это всегда риск

Этот кейс — не исключение, а довольно типичная история для проектов переезда в облако. Миграция инфраструктуры остается одной из самых рискованных ИТ‑задач, особенно если подготовка сводится к желанию «быстрее переехать» и общему плану без деталей.​

Исследования показывают, что компании регулярно недооценивают последствия таких решений. По данным отчета VMware Private Cloud Outlook 2025, почти половина организаций считают, что более 25% их расходов на публичные облака фактически уходят впустую — в том числе из‑за неудачных миграций и неоптимальной архитектуры. Аналитики Bloor Group отмечают, что свыше 80% проектов переноса данных выходят за рамки бюджета и сроков, причем средний перерасход по времени достигает 41%.​

Главные зоны риска хорошо видны и в нашем проекте.

• Бюджет. При миграции «как есть» в облако уезжают не только данные, но и все старые архитектурные проблемы. Поэтому даже после успешного переключения расходы продолжают расти: часть ресурсов простаивает, часть лицензий приходится докупать. В нашем случае дополнительные траты появились сразу — из‑за привязки лицензий к старому «железу» и вынужденных остановок процессов.​
• Сроки. Самый непредсказуемый фактор — данные и интеграции. На практике всплывают забытые связи между системами, старые форматы и архивы, о которых не было ни слова в документации. Так произошло и здесь: «типовой» переезд столкнулся с реальной сложностью накопленных данных и настроек.​
• Разрыв между планом и стратегией. Многие компании стартуют с красивым календарным графиком, но без продуманного сценария действий в случае ЧП. Эксперты Monte Carlo Data подчеркивают, что частая ошибка — отсутствие понятных критериев, когда нужно остановить миграцию и откатиться. В нашем проекте формальный план был, но ни четкой стратегии отката, ни критериев качества данных не прописали — это и превратило техническую задачу в затяжной стрессовый проект.​

Анатомия месяца авралов: что пошло не так

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

Вот 5 проблем, с которыми пришлось столкнуться на практике:

1. Не перенос, а пересборка.

На бумаге задача звучала как «переносим виртуальные машины». На деле на старой площадке был «зоопарк» из виртуальных и физических серверов. Старый провайдер физическое оборудование не отдавал. Пришлось фактически заново собирать инфраструктуру с нуля на новой площадке. Сроки поплыли моментально.

2. Лицензии и человеческий фактор.

Лицензии 1С и специализированного ПО были жестко привязаны к аппаратным USB-ключам на старых серверах. В облаке эти ключи, естественно, не заработали. Узнать об этом заранее без аудита было сложно: доступа к «железу» нам не давали. В итоге, пока производство ждало запуска, мы в экстренном режиме искали поставщиков и переоформляли лицензии.

3. Адресация и невидимые зависимости

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

4. Когда вы никому не нужны

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

5. Финал: перенос почтового сервера

Перенос корпоративной почты (Exchange) планировали на выходные. Из-за накопленных проблем процесс затянулся. Чтобы к утру понедельника завод мог писать письма, инженерам пришлось несколько суток подряд заниматься восстановлением без сна.

Работа над ошибками: как не попадать в такие истории

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

С тех пор у нас жесткое правило: никаких миграций без аудита. Вот наши выводы:

1. Аудит — сначала, а не «по дороге». Мы больше не верим на слово. Команда должна своими глазами видеть карту сети и привязки лицензий. Принцип простой: сначала диагностика, потом «лечение», и только затем — переезд.
2. Тестовая миграция (Пилот). Опора только на план — путь к провалу. Мы всегда настаиваем на пилотном переносе критичных сервисов в изолированную среду. Это позволяет поймать 80% проблем «на берегу».
3. Матрица ответственности (RACI). Чтобы избежать пинг-понга «это не наша задача», заранее расписываем каждый шаг: кто делает бэкап, кто настраивает сеть, кто тестирует 1С.
4. Проектный менеджер (PM) обязателен. Крупная миграция без выделенного PM гарантированно превращается в хаос. Экономия на управлении потом выливается в срывы сроков, которые стоят гораздо дороже.

Скупой платит дважды: почему аудит дешевле простоя

Миграция в облако — это сложная хирургическая операция. Никто не ложится под нож без анализов. В ИТ-принцип тот же.

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

Чек‑лист собственника: 6 вопросов перед стартом

Если вы планируете переезд, задайте эти вопросы своему ИТ-директору или подрядчику. Если хотя бы на один ответ «нет» или «не знаю» — вы в зоне риска.

1. Понимаете ли вы, какие конкретно сервисы перестанут работать, если отключить «неважный», на первый взгляд, сервер, и проверяли ли это в тестовом режиме.
2. Проведен ли аудит лицензий и есть ли список ПО, привязанного к «железу» (USB‑ключи, ID процессора), с пониманием можно ли при необходимости докупить лицензии или потребуется переход на аналоги, доступные в РФ.
3. Существует ли рабочий план отката: что вы будете делать, если новая площадка не поднимется к условным 4 утра понедельника.
4. Был ли пилот: тестировали ли вы критичные сервисы в отдельном контуре, или сразу планируете работать «по живому».
5. Есть ли матрица ответственности: кто конкретно отвечает за сеть, бэкапы, приложения — старый провайдер, новый или интегратор.
6. Назначен ли отдельный проектный менеджер, который координирует все стороны, или управление размыто между несколькими техническими специалистами.

Зачем все это собственнику

Эта история — не про «героев‑админов», а про цену управленческих решений. Мы осознанно вошли в рискованный проект и защитили бизнес-заказчика, но вывод однозначен: опора на авралы и самоотверженность команды — слишком дорогая стратегия. Миграция — это инженерный проект, где большая часть успеха закладывается на этапе скучного аудита, планирования и тестов, а не во время ночных созвонов.​

Если в планах переезд в облако или смена ЦОДа, лучше заранее проверить, насколько к этому готовы ваша инфраструктура и ИТ‑подрядчики.

Что забрать с собой

В нашем телеграм-канале мы делимся опытом и инструментами для управления ИТ. Недавно там вышел чек-лист «Как выбрать ИТ-партнера? Инструкция для собственника» — скачайте его, чтобы проверить текущего подрядчика и подготовиться к любым изменениям без стресса.