Меняется подрядчик — IT должно остаться управляемым
Смена IT-подрядчика опасна не самим расторжением договора. Основной риск — обнаружить в день перехода, что домен оформлен на чужую учётную запись, пароль администратора известен только одному человеку, резервные копии никто не проверял, а схема сети существует только «в голове» прежнего специалиста.
Поэтому переход нужно вести как отдельный управляемый проект. Его результат — не новый телефон Service Desk, а контролируемое владение инфраструктурой, доступами, документацией и открытыми обязательствами.
Что проверить до прекращения старого договора
До финальной даты обслуживания стоит собрать фактическую картину:
- оборудование и рабочие места;
- серверы, виртуальные машины и инфраструктурные роли;
- коммутаторы, маршрутизаторы, Wi‑Fi и VPN;
- облачные сервисы и подписки;
- домены, DNS и сертификаты;
- интернет-каналы и договоры с операторами;
- лицензии и сервисные контракты;
- резервные копии и способы восстановления;
- мониторинг;
- перечень открытых инцидентов и известных проблем;
- техническую документацию и схемы.
Если такой картины нет, IT-аудит позволяет сначала зафиксировать фактическое состояние, а уже потом планировать передачу.
Доступы и владение учётными записями
Важно различать «у нас есть пароль» и «компания действительно владеет сервисом».
Для домена, облака, виртуальной инфраструктуры, систем мониторинга, лицензий и других сервисов проверяется:
- на какую организацию зарегистрирована учётная запись;
- кто имеет административные права;
- есть ли независимый аккаунт, контролируемый заказчиком;
- куда приходят уведомления и коды восстановления;
- какие технические пользователи существуют;
- какие права нужно заменить или отозвать после перехода.
Пароли и ключи не следует пересылать в открытой переписке. Передача секретов выполняется через согласованный защищённый процесс.
Резервное копирование нужно проверить до перехода
Наличие задания backup ещё не доказывает возможность восстановления.
До критичного переключения нужно знать:
- какие данные и системы копируются;
- где находятся копии;
- кому принадлежит хранилище;
- когда была последняя успешная проверка;
- какой порядок восстановления;
- какие учётные данные потребуются, если основная инфраструктура недоступна.
Если backup зависит от аккаунта прежнего подрядчика, эту зависимость нужно устранить до завершения перехода.
Документация и известный технический долг
В идеальном сценарии заказчик получает актуальные схемы, перечни оборудования, настройки и инструкции. На практике часть документации может быть устаревшей или отсутствовать.
В таком случае новый подрядчик фиксирует:
- что передано и подтверждено;
- что приходится восстанавливать обследованием;
- какие сведения пока недостоверны;
- какие риски нельзя принять в регулярную эксплуатацию без дополнительных работ.
Так технический долг не превращается в скрытое обещание «мы теперь отвечаем вообще за всё».
Внешние поставщики и договоры
IT зависит от сторонних организаций: интернет-провайдеров, дата-центров, производителей, поставщиков ПО, сервисных центров и арендодателей.
При переходе важно определить:
- какие договоры принадлежат заказчику;
- где подрядчик выступал посредником;
- кто контактирует с поставщиком;
- какие SLA внешней стороны действуют;
- требуется ли перерегистрация контактов или кабинета;
- что произойдёт с услугой после прекращения старого договора.
Период передачи и контрольное переключение
Где возможно, безопаснее использовать короткий период контролируемого пересечения, а не переключение «в полночь с пятницы на субботу» без возможности уточнить детали.
План перехода может включать:
инвентаризация → сверка доступов → проверка backup → перенос документации → подключение мониторинга → перенос открытых задач → контрольный период → отзыв старых доступов.
Конкретная последовательность зависит от инфраструктуры и условий договора.
Открытые инциденты не должны исчезнуть
Все незавершённые задачи и известные проблемы фиксируются отдельным списком:
- что произошло;
- какое влияние есть на бизнес;
- что уже делалось;
- какая сторона сейчас отвечает;
- какие внешние поставщики участвуют;
- есть ли временный обход;
- что нужно сделать после перехода.
Новый Service Desk должен получить этот список как управляемый backlog, а не начинать историю с нуля.
Если прежний подрядчик не сотрудничает
Такой сценарий нужно рассматривать отдельно. Возможные действия зависят от того, чем юридически и технически владеет заказчик.
Обычно требуется:
- восстановить независимые административные права;
- перевыпустить или сменить пароли и ключи;
- перенести управление доменами и сервисами;
- обследовать сеть и серверы;
- восстановить документацию;
- проверить резервные копии;
- определить неизвестные зависимости до отключения старых доступов.
Нельзя обещать мгновенную передачу системы, к которой у заказчика фактически нет административного или договорного доступа.
Как SoftTech принимает инфраструктуру
Мы начинаем с границ: что переходит в ответственность SoftTech, что остаётся у заказчика и какие внешние сервисы нужно только координировать.
После этого формируется план приёмки, подключается Service Desk, мониторинг и согласованный SLA. Регулярная эксплуатация начинается после того, как критичные неизвестные риски либо устранены, либо явно приняты сторонами.
Исторический пример такого перехода опубликован в кейсе KFC Belarus. Сотрудничество завершено в мае 2026 года; кейс используется как подтверждение выполненной работы, а не как заявление о текущем контракте.
Обсудить смену подрядчика
Для первого разговора достаточно описать размер инфраструктуры, количество объектов, дату завершения текущего договора и основные риски. Секреты и пароли через форму передавать не нужно.