Как выбрать подрядчика для миграции ИТ-инфраструктуры и не потерять контроль над проектом

Миграция серверов, почтовых систем или целых доменов — это не разовая техническая операция, а полноценный проект, где переплетаются архитектура, бизнес-процессы и управление рисками. В моей практике проектного управления и ИТ-аудита я не раз убеждался: успех на 70% зависит от того, насколько грамотно выбран исполнитель и насколько прозрачно выстроено взаимодействие. Когда подрядчик работает как «чёрный ящик», а заказчик довольствуется лишь обещаниями, контроль над сроками, бюджетом и целостностью данных теряется буквально на первом же этапе. Поэтому дальше — не просто список критериев, а системный взгляд, построенный на опыте сложных инфраструктурных переходов. Здесь будет тот же подход, что и при обустройстве территории: сначала обследуем, потом проектируем, затем действуем — и только так получаем предсказуемый результат.

Почему миграция ИТ-инфраструктуры — это проект, а не техническая задача

Миграция Active Directory, Exchange, виртуализации или переход на отечественное ПО напоминает перестройку сложных инженерных систем на участке: сначала изучают рельеф и коммуникации, потом разрабатывают схему, определяют этапы, проверяют совместимость и только затем приступают к реализации. Если пропустить обследование, последствия неизбежны — что в дренажной системе, что в ИТ-инфраструктуре.

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

Основные риски при неправильном выборе подрядчика

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

Этап 1: Подготовка и аудит текущего состояния

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

Что должен включать аудит

1. Оценка текущего состояния: полная инвентаризация серверов, сетевого оборудования, установленного ПО, учётных записей и их взаимосвязей. Это как топосъёмка участка — без неё не построить работающую систему водоотведения.
2. Выявление рисков: поиск уязвимостей, несовместимостей, устаревших версий, которые могут не пережить миграцию. Например, старые драйверы или самописные скрипты, завязанные на конкретную версию ОС.
3. Анализ бизнес-процессов: определение типов пользователей и ключевых процессов, зависящих от ИТ-систем. Это помогает правильно расставить приоритеты и понять, какие сервисы нельзя трогать в рабочее время.
4. Составление дорожной карты: план перехода с этапами, сроками, необходимыми ресурсами и контрольными точками.

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

Как подготовить техническое задание (ТЗ)

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

Что обязательно включить в ТЗ:

• Цели миграции: что именно меняем — например, «перенос Exchange на российское ПО» или «миграция Active Directory на Linux-based контроллеры».
• Требования к совместимости: какие системы должны продолжать работать вместе после миграции, включая смежные сервисы (ERP, CRM, файловые хранилища).
• Ограничения: бюджет, сроки, допустимые окна простоя, доступность серверов в рабочее время.
• Критерии успеха: измеримые показатели — «0 потерь данных», «время восстановления не более 1 часа», «отклонение производительности не более 5%».
• План возврата (Rollback): условия и порядок возврата к исходному состоянию при критическом сбое. Это обязательный пункт, как план эвакуации на случай пожара.

Хорошее ТЗ — это не бюрократия, а страховка от сюрпризов. Оно позволяет сравнивать предложения разных подрядчиков на одном основании и служит эталоном при приёмке работ.

Этап 2: Критерии выбора подрядчика

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

1. Опыт и реальные кейсы

Запросите кейсы с аналогичной инфраструктурой и из вашей отрасли. Если вы из e-commerce, спросите, как подрядчик решал задачи с высокой нагрузкой в дни распродаж: как обеспечивалась отказоустойчивость, какие механизмы кэширования применялись, как проходило тестирование под нагрузкой.

Что проверять в кейсах:

• Измеримые результаты: конкретные цифры — сокращение простоев на X%, оптимизация затрат на Y рублей в месяц, успешные миграции без потери данных.
• Свежие проекты: референсные проекты по вашей специфике за последние 1–2 года. Технологии быстро меняются, и опыт пятилетней давности может быть нерелевантен.
• Детали решения: как решались вопросы синхронизации данных, обработки ошибок, мониторинга. Это покажет глубину компетенций.
• Референсы: контакты минимум трёх референс-клиентов для проверки. Личный разговор с бывшим заказчиком часто вскрывает то, что не написано в буклетах.

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

2. Структура команды и квалификация

Enterprise-проект требует не просто senior-разработчиков, а слаженной команды с чётким распределением ролей: архитектор, DevOps-инженер, QA-автоматизатор, технический писатель и специалист по информационной безопасности. Попытка закрыть всё одним «full-stack»-универсалом в сложной миграции обычно заканчивается тем, что страдает либо безопасность, либо качество документирования, либо автоматизация тестирования.

Красные флаги:

• Ответ «у нас есть full-stack» вместо описания структуры команды и зон ответственности.
• Исполнитель — просто диспетчер, передающий задачи фрилансерам, без постоянного штата инженеров.
• Нет штатных инженеров с авторизованными сертификатами (Microsoft, Cisco, ISO 27001 и т.п.).

Что спросить:

• Кто будет вашим основным контактным лицом? Это должен быть технический менеджер или product owner, а не менеджер по продажам, который исчезнет после подписания договора.
• Есть ли у специалистов сертификаты о прохождении авторизованных курсов и сдаче экзаменов? Наличие сертификации — не гарантия гениальности, но подтверждение системного обучения.
• Как выстроены внутренние процессы: регулярные ревью кода, автоматизированное тестирование, документирование архитектуры? По ответам станет понятно, есть ли у компании культура качества.

3. Технические компетенции и стек технологий

Проверьте поддерживаемый стек технологий: Windows, Linux, VMware, облачные платформы, Kubernetes. Особенно важно, чтобы подрядчик имел опыт работы с теми продуктами, которые планируется внедрять, и с теми, от которых вы уходите.

Критические вопросы для российского рынка:

• Используют ли они российские хостинги (Selectel, МТС, VK Cloud) и имеют ли опыт миграции с AWS/GCP на локальные решения?
• Как решают вопрос с библиотеками с открытым исходным кодом в условиях санкций — есть ли проработанные цепочки поставки и аудит зависимостей?
• Имеют ли аккредитацию ИТ-компании (даёт налоговые льготы, повышает доверие госзаказчиков и подтверждает официальный статус).

4. Репутация и независимые рейтинги

Изучите независимые рейтинги: TAdviser, RAEX, Clutch. Проверьте, является ли провайдер членом профильных ассоциаций. Это не панацея, но один из индикаторов зрелости.

Юридическая проверка:

• Выписка из ЕГРЮЛ: отсутствие судебных споров и задолженности перед ФНС. Даже небольшой текущий спор может сигнализировать о проблемах с исполнением обязательств.
• Наличие аккредитации Министерства цифрового развития — это маркер, что компания прошла определённый фильтр и признана государством.

5. Условия сотрудничества и SLA

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

Что обязательно прописать в SLA:

• Конкретные цифры: «реакция на критический инцидент — 5 минут, решение — 1 час», а не «максимально быстро». Расплывчатые формулировки — это отсутствие обязательств.
• Приоритеты инцидентов: система должна учитывать влияние на бизнес — сломанный принтер ≠ упавший сервер 1С. Определите уровни критичности и соответствующие нормативы.
• Финансовая ответственность: суммы штрафов за нарушение сроков, прописанные прямо в договоре. Если штраф символический, он не работает как стимул.
• NDA (соглашение о конфиденциальности): особенно важно, если подрядчик получает доступ к чувствительным данным.

Этап 3: Оценка предложений и переговоры

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

Вопросы для переговоров:

1. «Какие у вас реальные финансовые гарантии в SLA?» — требуйте конкретные суммы штрафов, а не общие фразы.
2. «Как вы будете проводить пилотное тестирование на группе серверов?» — оценка совместимости и производительности на малом масштабе снижает глобальные риски.
3. «Какой у вас план возврата к исходному состоянию при непредвиденных ситуациях?» — попросите показать документ, а не устное заверение.
4. «Как вы отслеживаете качество кода, как проводите деплой и реагируете на инциденты?» — ответы покажут реальный уровень DevOps-практик.

Чем выше требования к SLA, тем больше ресурсов нужно держать в резерве, а значит, выше цена. Не выбирайте самый дешёвый вариант, если он не гарантирует критическую скорость реакции — экономия здесь обманчива.

Чек-лист проверки подрядчика перед заключением договора

Используйте этот чек-лист для финальной оценки. Если подрядчик не отвечает на большинство пунктов — это повод отказаться от сотрудничества.

📋 Базовая проверка

• Есть аккредитация ИТ-компании или Министерства цифрового развития.
• Выписка из ЕГРЮЛ: нет судебных споров и задолженностей перед ФНС.
• Провайдер — член профильных ассоциаций.
• Есть независимые рейтинги (TAdviser, RAEX, Clutch).

📋 Опыт и кейсы

• Есть свежие кейсы (1–2 года) по вашей специфике.
• Кейсы с измеримыми результатами (сокращение простоев, оптимизация затрат).
• Контакты минимум 3 референс-клиентов для проверки.
• Опыт в импортозамещении и конкретно в типе вашего проекта.

📋 Команда и компетенции

• Есть штатные инженеры с авторизованными сертификатами (Microsoft, Cisco, ISO).
• Чёткая структура команды: архитектор, DevOps, QA, специалист по ИБ (не только full-stack).
• Основной контакт — технический менеджер/product owner, а не продавец.
• Поддерживаемый стек: Windows, Linux, VMware, Kubernetes, российские облака.

📋 Процессы и гарантии

• Есть план аудита перед началом работ (дорожная карта перехода).
• Проводится пилотное тестирование на группе серверов.
• Есть план возврата (rollback) при сбое.
• В договоре прописаны конкретные цифры SLA (реакция, решение, штрафы).
• Есть NDA (соглашение о конфиденциальности).
• Прозрачная структура цены: абонент + доп. услуги + переменные.

Типичные ошибки заказчиков и как их избежать

Ошибка 1: Фокус на цене, а не на компетенциях

Суть: заказчик выбирает самого дешёвого подрядчика, не проверяя опыт и гарантии.
Риск: срыв сроков, потеря данных, длительная остановка бизнес-процессов.
Как избежать: сравнивайте не только цену, но и SLA, реальные кейсы, структуру команды. Цена ошибки в миграции часто многократно превышает разницу в бюджетах между подрядчиками.

Ошибка 2: Отсутствие детального ТЗ

Суть: заказчик даёт размытое задание: «перенесите почту».
Риск: аутсорсер превращает неизвестные переменные в дополнительные риски и раздувает стоимость.
Как избежать: проработайте ТЗ тщательно: все требования, нюансы, ограничения должны быть детально описаны. Это как проект дренажной системы: без точных уклонов и расчётов вода пойдёт не туда.

Ошибка 3: Непроверенная команда

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

Ошибка 4: Отсутствие плана возврата

Суть: заказчик не требует плана rollback при сбое миграции.
Риск: полная потеря данных, невозможность вернуться к старой версии.
Как избежать: обязательно включите в ТЗ план возврата к исходному состоянию и создайте актуальные резервные копии данных перед миграцией. Это как дренажный колодец на случай ливня — должен быть, даже если надеетесь на хорошую погоду.

Ошибка 5: Размытые SLA

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

Пошаговый план миграции: от выбора подрядчика до завершения

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

Шаг 1: Аудит и планирование

1. Проведите полный ИТ-аудит вместе с подрядчиком — это совместная работа, а не односторонний акт.
2. Составьте дорожную карту перехода с этапами, сроками, ресурсами и контрольными точками.
3. Определите типы пользователей и ключевые бизнес-процессы, зависящие от ИТ, чтобы ранжировать критичность.

Шаг 2: Выбор и тестирование решений

1. Проанализируйте доступные на российском рынке программные продукты и их совместимость с вашей экосистемой.
2. Выберите подходящие решения и проведите комплексное тестирование на пилотной группе серверов — это как пробный запуск системы полива на одном секторе.
3. Оцените совместимость и производительность в условиях, максимально приближенных к реальной эксплуатации.

Шаг 3: Подготовка к миграции

1. Создайте актуальные резервные копии данных — полные, проверенные, с возможностью быстрого восстановления.
2. Разработайте детальный план возврата к исходному состоянию (rollback) с указанием ответственных и таймингов.
3. Убедитесь, что подрядчик имеет сертификаты и опыт в импортозамещении, особенно в части поддержки после миграции.

Шаг 4: Миграция и мониторинг

1. Выполните миграцию строго по дорожной карте, не пропуская промежуточные проверки.
2. Проводите регулярный мониторинг и ревью качества: автоматизированные тесты, логи, ручная проверка ключевых сценариев.
3. Тестируйте обработку ошибок и синхронизацию данных на каждом этапе, а не только в конце.

Шаг 5: Завершение и поддержка

1. Подтвердите успешное завершение по критериям из ТЗ — объективно, с цифрами.
2. Зафиксируйте все договорённости по дальнейшей поддержке в договоре с SLA.
3. Установите процесс поддержки: Helpdesk, мониторинг, регламент обновлений — чтобы система продолжала жить, а не «замерла» после миграции.

FAQ: Ответы на частые вопросы

Как долго длится миграция ИТ-инфраструктуры?

Длительность зависит от масштаба проекта: от нескольких недель для простой миграции почты до нескольких месяцев для комплексной перестройки (Active Directory, виртуализация, ОС). Ключевой фактор — качество аудита и детализация ТЗ. Чем тщательнее подготовка, тем быстрее и предсказуемее сама миграция.

Что делать, если подрядчик не укладывается в сроки?

В договоре должны быть прописаны конкретные суммы штрафов за нарушение сроков. Если SLA размыто («максимально быстро»), требуйте пересмотра договора с конкретными цифрами. Также используйте план возврата (rollback), если миграция не удалась — это даёт возможность откатиться без катастрофы.

Можно ли миграцию провести без аудита?

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

Какие сертификаты должны быть у специалистов подрядчика?

Специалисты должны иметь авторизованные сертификаты (Microsoft, Cisco, ISO 27001 Lead Implementer) и пройти авторизованные курсы. Инвестиции компании в обучение сотрудников свидетельствуют о серьёзном подходе к развитию компетенций.

Что включать в SLA для миграции?

В SLA должны быть: конкретные цифры реакции и решения (например, 5 минут / 1 час), приоритеты инцидентов с учётом влияния на бизнес, финансовая ответственность (суммы штрафов), а также NDA (конфиденциальность).

Как проверить, что подрядчик не просто диспетчер фрилансеров?

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

Нужно ли использовать российские хостинги и ПО?

Да. Для российского рынка критически важно использовать российские хостинги (Selectel, МТС, VK Cloud) и иметь опыт миграции с AWS/GCP на локальные решения. Опыт в импортозамещении — первостепенный критерий, особенно в текущих условиях.

Что делать, если при миграции потеряны данные?

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

Вывод

Выбор подрядчика для миграции ИТ-инфраструктуры — стратегическое решение, где цена ошибки многократно превышает разницу в бюджетах. Ключ к успеху — не в поиске самого дешёвого исполнителя, а в тщательной проверке опыта, компетенций, структуры команды и гарантий качества (SLA).

Главное правило:

1. Проведите полный аудит перед началом работ.
2. Запросите реальные кейсы с измеримыми результатами из вашей отрасли.
3. Проверьте штатных инженеров с авторизованными сертификатами.
4. Включите в договор конкретные цифры SLA и суммы штрафов.
5. Обязательно разработайте план возврата (rollback) при сбое.

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