Облако · 15 мин чтения

5 ошибок миграции в облако: разбор провального переезда клиента

Меня позвали как "скорую помощь" на третьей неделе провальной миграции. Бухгалтерия не печатает счета, на цеху встал учёт смен, директор нанял адвоката против старого подрядчика. Пришлось разгребать. Разбираю пять ошибок, которые превратили простой переезд в командировку в ад на 1.5 месяца.

Я Семёнов Евгений Сергеевич, 15 лет в IT-инфраструктуре малого бизнеса. За эти годы провёл и восстановил больше двадцати миграций. Этот кейс — учебник того, как делать не надо. Имена скрыты, цифры реальны.

Контекст: что и куда переезжало

Клиент — производство металлоконструкций на 47 рабочих мест: офис в Москве на Дубровке, цех в Балашихе. На старой площадке всё крутилось на двух физических серверах HP DL380 G8 в стойке у местного провайдера.

Что было:

Цель — переехать в Yandex Cloud в формате IaaS, чтобы избавиться от 280 тыс. рублей ежемесячных платежей за хостинг и колокацию. Новый бюджет в облаке оценили в 95 тыс. рублей. Экономия — миллион двести в год. Идея здоровая. Реализация — нет.

Хронология провала

Заказ ушёл интегратору, который никогда не делал миграции с физикой. Они продали "под ключ" за 380 тыс. рублей, обещали 2 недели работ и нулевой простой. План выглядел как пять шагов на одной странице. Дальше события:

Ошибка №1: отсутствие предпроектного аудита

Симптом

Интегратор пришёл, посмотрел дашборд Hyper-V, спросил "сколько у вас места и памяти", и составил смету.

Что не учли

Как должно было быть

Минимум 5 рабочих дней на аудит до подписания договора. Инвентаризация всех сервисов, зависимостей, лицензий, интеграций. Карта в формате Service → Depends_on → IP/FQDN/License минимум на одной странице. У нас есть шаблон такого аудита — он занимает около 80 пунктов для типового офиса 30 человек.

Ошибка №2: переименование домена и потеря AD-объектов

Симптом

В облаке подняли свежий домен company.local вместо старого klient.lan. Пользователей переносили скриптом без групп, без атрибутов, без SID-history.

Последствия

Как надо было

Если есть возможность — сохранять имя домена. Если нет — использовать ADMT (Active Directory Migration Tool) с миграцией SID-history. Это даёт пользователям сохранить доступ к ресурсам, как если бы домен и не менялся. Бывает работа на 2-3 дня вместо двух недель восстановления:

# Пример миграции пользователей через ADMT с SID-history:
Set-Location 'C:\Program Files\Active Directory Migration Tool'
.\admt user /N "u_buh1" /SD:"klient.lan" /SDC:"OLD-DC01.klient.lan" `
   /TD:"company.local" /TDC:"NEW-DC01.company.local" /TO:"Users" `
   /MSS:Yes /UUR:CopyUserRights /PS:"new_account_pwd_csv.txt"

Ошибка №3: миграция файлов через robocopy без NTFS-прав

Симптом

Команда интегратора запустила robocopy /MIR без флагов сохранения прав, владельцев и атрибутов. На новом сервере пришлось руками назначать всё.

Правильная команда выглядит так

robocopy \\OLD-FILES\Share \\NEW-FILES\Share /MIR /COPYALL /B /R:3 /W:5 \
  /MT:16 /XJ /LOG+:robocopy.log /TEE
# /COPYALL = data + attributes + timestamps + NTFS ACL + owner + auditing
# /B = backup mode (читать игнорируя ACL)
# /MIR = mirror (с удалением)
# /MT:16 = 16 потоков

Дополнительно — перед массовым копированием делается тест на тестовой папке и проверяется, что Get-Acl на новом сервере возвращает корректные SID. Если SID старого домена — нужна миграция через SIDHistory или повторное назначение прав через скрипт.

Что мы сделали для исправления

Написал PowerShell-скрипт, который читал отчёт прав со старого сервера через icacls, маппил группы старого домена на новый по таблице соответствия и применял заново. На 4.7 ТБ файлов и 1240 папок ушло 14 часов работы машины и 6 часов на проверку.

Ошибка №4: лицензии не учли в смете

Симптом

1С не запускалась — HASP-ключ остался воткнут в старую материнку. Autodesk требовал переактивацию по новому MAC. Microsoft Office работал из-за GVLK, но KMS-сервер был на старом контроллере, новый Volume License не был активирован.

Что нужно было сделать заранее

В нашем кейсе 1С простояла дополнительно 4 дня в ожидании электронных пинкодов от 1С. Все эти 4 дня бухгалтерия выписывала счета в Word.

Ошибка №5: миграция продакшена без пилота и плана отката

Симптом

Старый сервер остановили в субботу утром, начали переносить виртуалки в облако. К воскресенью вечером не запустились ни 1С, ни Exchange. Откатываться было нечего — старый Hyper-V уже был частично разобран, диски сняты, провайдер отключил услугу с понедельника.

Что должен был включать план

  1. Пилотный сервис. Переносим один некритичный сервис (например, intranet) и держим его в облаке две недели. Учимся на нём.
  2. Параллельная работа. Старые серверы не выключаются до полного перекрёстного теста новой среды. Оплата провайдеру за лишний месяц — копейки относительно простоя.
  3. План отката. Документ из 5-7 пунктов, что делаем, если в момент X не работает Y. Например: "Если Exchange в облаке не принимает почту в течение 2 часов — переключаем MX обратно на старый сервер, откатываем DNS, поднимаем старый сервер, запускаем postpending-очередь".
  4. Снапшоты на старте. Перед миграцией — снапшот всех виртуалок на старом гипервизоре. Возврат — в 5 минут.
  5. Стоп-кран. Чёткие критерии отказа от миграции на любом этапе. Например: "если время простоя превышает 4 часа — откат, разбор, новая попытка через неделю".

Как мы спасли проект

На пятой неделе я приехал в офис клиента с двумя инженерами. План восстановления:

  1. День 1-2. Полный аудит того, что сделано. Составление карты "что работает / что не работает / что сломано необратимо". Получилось 87 пунктов проблем.
  2. День 3. Разговор с заказчиком. Объяснил, что старый интегратор не справится, нужно переделать AD и файловый сервер. Получил подтверждение и временный бюджет на параллельные мощности.
  3. День 4-5. Поднял дополнительный сервер у Selectel (не Yandex — для распределения рисков), на нём — временный AD с правильным именем домена и SID-history, временный файловый сервер с правами в полном объёме, восстановленный из вчерашнего бэкапа Synology.
  4. День 6-9. Переключение пользователей на временный AD через trust-отношения, постепенное восстановление прав, заведение новых GPO, установка KMS, активация всех лицензий через корпоративные кабинеты.
  5. День 10-14. Восстановление 1С: получили электронные пинкоды, развернули MSSQL 2019 с restore из недельного бэкапа + догон через transaction logs, запустили регламентные задачи под правильными UNC-путями.
  6. День 15-19. Exchange: подняли заново на отдельной виртуалке, перенесли почту через Public Folder Migration и New-MoveRequest, согласовали MX-записи с новым IP, выправили SPF/DKIM/DMARC.
  7. День 20-25. Финальная консолидация: перенос мощностей с временного сервера обратно в Yandex Cloud по плану с пилотом и откатом, на этот раз с правильной картой зависимостей.

Итог: миграция, которая должна была занять 2 недели и 380 тыс. рублей, реально заняла 9 недель и обошлась клиенту в 1.7 млн рублей плюс примерно 4 млн упущенной выручки за дни простоя. Старого интегратора клиент через суд не достал — у того в договоре было прописано "результат работ — поднятая виртуальная инфраструктура", и формально она была поднята.

Чек-лист правильной миграции в облако

ЭтапДлительностьЧто делаем
1. Аудит5-10 раб. днейИнвентаризация серверов, сервисов, зависимостей, лицензий, интеграций. Карта зависимостей.
2. Дизайн3-5 раб. днейАрхитектура целевой инфраструктуры, схема сети, расчёт ресурсов, бюджет, SLA.
3. Подготовка5-7 раб. днейПоднятие инфраструктуры в облаке, VPN-канал к офису, базовые шаблоны, мониторинг.
4. Пилот3-5 раб. днейПеренос одного некритичного сервиса, тестовая эксплуатация, корректировка планов.
5. Основная миграция5-15 раб. днейПеренос сервисов в правильном порядке, параллельная работа со старой средой.
6. Перекрёстное тестирование3-5 раб. днейПрогон бизнес-процессов, проверка интеграций, нагрузочное тестирование.
7. Cutover1-2 ночиФинальный синк данных, переключение DNS/MX, отключение старой среды.
8. Поддержка2-4 неделиДежурство, оперативное реагирование на хвосты, оптимизация затрат в облаке.

Главные мысли

  1. "Облако" — это не магия. Это другая инфраструктура с собственными граблями. Без подготовки переезд в облако ломает то же самое, что переезд в новый офис без планировки.
  2. Без аудита не подписывайте договор. Если интегратор готов оценить миграцию по списку виртуалок — это плохой знак.
  3. Лицензии — отдельная история, требующая 2-3 недели работы с вендорами. Закладывайте время.
  4. Пилот экономит десятки часов авралов. Не пропускайте этот этап.
  5. Старая инфраструктура должна жить параллельно с новой минимум 2 недели. Лишние деньги за этот месяц провайдеру — лучшая страховка.

Бесплатный аудит инфраструктуры от ITfresh

Если вы планируете миграцию в облако или подозреваете, что текущий проект едет под откос — приду на 2 часа и оценю риски. Карта зависимостей, реалистичный план, ориентир по бюджету. Бесплатно для компаний 10-50 рабочих мест в Москве.

Telegram: @ITfresh_Boss
Телефон: +7 903 729-62-41

Часто задаваемые вопросы

Сколько времени занимает миграция офиса 30 рабочих мест в облако?

При нормальной подготовке — 4-8 недель календарно. Без аудита проект растягивается до 4-6 месяцев и заканчивается ночными авралами.

Что дешевле: своё железо или облако?

Зависит от 3-летнего горизонта и темпа роста. На малых масштабах облако обычно дороже на 30-60%, но даёт гибкость. Ответ всегда в TCO-расчёте.

Что брать: IaaS, PaaS или приватное облако?

В России в 2026 году популярен IaaS у Yandex Cloud, Selectel, VK Cloud. Приватный VDC — у Servermall или 1cloud для контура с 1С. Гибрид для совмещения.

Что делать с лицензиями 1С при переезде в облако?

Либо проброс USB-ключа (UsbHasp, AnywhereUSB), либо переход на программные лицензии с переактивацией через 1С. Срок 3-7 рабочих дней, планируйте заранее.

Можно ли обойтись без тестовой миграции?

Нет. Без пилота вы не знаете реальные тайминги и не выявите скрытые зависимости. Это самый недооценённый этап в проектах малого бизнеса.