Как завершить миграцию в облако, если она затягивается.

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

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

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

Как зависает «успешный пилот»

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

Второй сценарий — бесконечная подготовка. Сетевые правила, права доступа, мониторинг, бэкапы, политика секретов — всё важно, но без даты переключение и критерия готовности подготовка становится образом жизни. Команда всегда «почти готова» и никогда не переключает.

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

Ошибки, которые гарантируют пробуксовку

Нет владельца миграции с мандатом останавливать лишний объём работ. Без него каждый отдел добавляет «раз уж переезжаем» — и проект расползается в большой ремонт всего сразу.

Нет карты зависимостей. DNS, сертификаты, очереди, внешние IP в белых списках, cron-задания, платёжные колбэки — всё это всплывает в ночь переключения, когда чинить уже поздно и дорого.

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

Путают миграцию инфраструктуры с переписыванием приложений. Если цель — облако «как есть», не смешивайте её с большим рефакторингом в том же окне. Это два проекта с разным риском и разной пользой.

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

Чек-лист для завершения миграции

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

Соберите инвентарь и зависимости: приложения, данные, интеграции, DNS, секреты, лицензии, каналы, кто должен быть на связи в окно и кто принимает решение «продолжаем или стоп».

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

Поднимите целевой контур с мониторингом, бэкапами и доступом поддержки до переключения, а не «настроим после, если всё ок». После — уже поздно учиться жить в новом мире.

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

Заморозьте изменения на старом контуре на короткий контролируемый срок. Без-freeze-переключение всегда будет «ещё не сейчас», потому что цель будет убегать.

Опишите откат так же подробно, как перенос. Команда спокойнее идёт в окно, когда знает обратный путь и критерии его запуска.

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

Как вытащить уже застрявшую миграцию

Назначьте дату принятия решения: либо переключение в ближайшее окно при выполнении чеклиста, либо честный перевод проекта в паузу с остановкой двойных затрат. Вечный статус «почти готовы» дороже любого выбранного варианта — он съедает деньги и внимание без результата.

Урежьте объём работ до того, что реально даёт бизнес ценность в первом заходе. Остальное — волна два с отдельным планом. Первая ценность важнее идеальной полноты.

Закройте технические долги пилота: то, что обошли «для демо», теперь блокер. Лучше потратить две три недели на зависимости, чем ещё полгода на страх и двойную оплату.

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

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

Что получает бизнес после завершения

Один актуальный контур вместо двойной оплаты и двойной поддержки. Предсказуемые сроки изменений. Возможность масштабироваться без ритуала «трогать старое железо страшно» и без вечного статуса миграции в каждом плане квартала.

Главный эффект — возврат управленческого внимания. Миграция отнимает много времени на обсуждения и планирование, отвлекая от других важных задач. Закрытый переключение освобождает команду для развития, а не для удержания двух миров.

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

Пилот — это доказательство возможности. Ценность появляется только после переключения. Если прод «не трогаем месяцами», миграция ещё не началась по настоящему — она только красиво застряла на полпути.