Смена ИТ-подрядчика: что обязан передать прежний и как принять ИТ-инфраструктуру

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

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

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

Коротко. Передача ИТ-дел считается состоявшейся не тогда, когда прислали архив с паролями, а тогда, когда по каждой позиции перечня есть проверяемое доказательство: успешный вход новой команды под своей учётной записью, восстановленный из резервной копии тестовый экземпляр, дошедший до нового адресата алерт, полученный файл конфигурации. Доступы прежнего ИТ-подрядчика отзываются после приёмки, и отзыв тоже проверяется.

Что определяем до первого пароля

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

Граница состава. Что именно принимает новая команда: рабочие места и пользователи, серверы и виртуализация, сеть и Wi-Fi, облачные сервисы, почта, 1С, резервное копирование, телефония, видеонаблюдение. Отдельным списком — что не входит: доработка конфигураций 1С, сайт у веб-студии, оборудование на гарантии поставщика, услуги оператора связи. Сервис, не попавший ни в один список, обычно и оказывается тем, который перестаёт работать первым.

Граница времени. Дата и время, с которых новая команда отвечает за заявки по каждой системе. Не «с октября», а «с 6 октября 10:00 по всем системам, кроме 1С; по 1С — с 13 октября, после проверки восстановления».

Граница ответственности. Кто со стороны компании принимает работу и подписывает акт. Не должность «системный администратор», которой в компании может не быть, а конкретный руководитель, вправе сказать «принято» и «не принято».

Если перечня систем нет вообще, начинать надо не с переписки с подрядчиком, а со своей таблицы: реестр ИТ-активов компании — это ровно тот документ, который делает приёмку проверяемой. Без него вы сверяете переданное с тем, что вам прислали, а не с тем, что у вас есть.

Состав передачи: восемь групп

Перечень ниже не список пожеланий, а рабочий каркас акта. Внутри каждой группы — то, что реально теряется при переходах.

1. Доступы и учётные записи. По каждой системе: кто получает доступ, с какими правами, каким способом. Отдельно — доменные и локальные административные учётные записи, VPN, SSH-ключи, панели хостинга и регистратора домена, кабинет почтовой организации, гипервизор и система хранения, панели сетевого оборудования, IPMI/iDRAC, API-токены интеграций. Сами пароли передаются через защищённое хранилище, а в акте фиксируется ссылка на запись и факт передачи — не значение секрета.

2. Документация. Схема сети и адресация, паспорта серверов и виртуальных машин, описание того, что где развёрнуто и от чего зависит, регламенты, инструкции по типовым операциям, история изменений за год. Актуальность оценивайте сразу: схема двухлетней давности — исходные данные для обследования, а не переданная документация.

3. Лицензии и подписки. На кого оформлены (компания или подрядчик), где лежат ключи и лицензионные файлы, дата продления, кто платит и с какого счёта. Подписки, оформленные на юрлицо подрядчика, — самая частая причина того, что через месяц после перехода отключается антивирус или почтовый тариф.

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

5. Мониторинг и алерты. Что именно контролируется, куда приходят события, кто на них реагирует ночью. Типичная находка: алерты приходили в личный мессенджер инженера прежней команды, и после его ухода никто не узнал, что сломался бэкап.

6. Заявки и история обращений. Открытые заявки с текущим статусом, известные проблемы и временные обходные решения, запланированные работы, выгрузка истории обращений хотя бы за год. История — это карта того, что ломается регулярно.

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

8. Физическое оборудование. Серверы, коммутаторы, точки доступа, ИБП, накопители, токены и ключи от серверной: перечень, серийные номера, состояние, гарантия, где физически находится. Сюда же — оборудование подрядчика, которое он забирает.

Отдельно про домен. Если он зарегистрирован на подрядчика, передача права администрирования — самостоятельная процедура, а не смена контактов. По постановлению Правительства РФ от 31.08.2026 № 1119 заявку подаёт текущий администратор и проходит идентификацию (пункт 61), получатель тоже проходит идентификацию и заключает договор с тем же регистратором (пункт 62), регистратор исполняет заявку в течение трёх рабочих дней. Передача не допускается в период преимущественного продления и в течение 30 дней с момента, когда текущий администратор сам получил право на домен (пункт 64). Планируйте это не на последнюю неделю перехода.

Таблица приёмки: доказательство вместо обещания

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

Условный пример заполненной строки: «Резервное копирование CRM; тестовое восстановление копии за 28 сентября в изолированной среде; протокол TEST-04 от 30 сентября; принял руководитель отдела продаж; замечание — внешняя интеграция с телефонией в тесте не проверялась».

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

Подробнее про сам порядок проверки копий — в материале про тестовое восстановление из резервной копии; дублировать протокол здесь незачем.

Акт передачи ИТ-дел

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

Что в нём должно быть:

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

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

Переходный период: кто за что отвечает

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

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

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

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

Как переключается ИТ-поддержка

Принятая инфраструктура и работающая ИТ-поддержка — не одно и то же. Пользователям нужен один понятный маршрут.

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

Информирование сотрудников — короткое письмо: с какого числа, куда обращаться, что писать в заявке, куда эскалировать критичное. Одна страница, без описания архитектуры.

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

Отзыв доступов прежнего ИТ-подрядчика

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

Проверяем по списку и фиксируем результат:

• доменные, локальные и сервисные учётные записи, включая созданные «для задачи» и забытые;
• VPN-профили и сертификаты, а также активные сессии — отключение учётной записи не всегда завершает уже выданную сессию или токен;
• SSH-ключи в authorized_keys на каждом сервере, а не только на основном;
• панели хостинга, регистратора домена и DNS, включая дополнительных пользователей кабинета;
• почтовая организация: административные роли, правила пересылки, делегированные ящики;
• мониторинг, системы удалённого управления и RMM-агенты подрядчика;
• репозитории, CI/CD и автоматизации;
• API-токены и ключи интеграций — их перевыпускают, а не «отключают пользователя»;
• доступ к хранилищам резервных копий и ключам шифрования архивов.

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

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

Что предусмотреть в договоре заранее

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

1. Все учётные записи и активы оформляются на компанию. Домен, хостинг, облачные подписки, лицензии, кабинеты платформ — сторона договора и администратор указываются как юридическое лицо заказчика, даже если оплату технически проводит подрядчик.
2. Обязанность вести документацию и передавать её. С перечнем: схема, паспорта систем, регламенты, история изменений. И с периодичностью актуализации, иначе документация появляется один раз при старте.
3. Порядок и срок передачи дел при расторжении. Состав передаваемого, форма акта, срок, порядок оплаты работ по передаче. Универсального законного срока уведомления нет — он берётся из вашего договора.
4. Доступ компании к резервным копиям. Копии должны храниться там, где компания имеет к ним самостоятельный доступ, с известными ключами шифрования.
5. Условия поддержки на переходный период. Отдельная строка в SLA: приоритеты, реакция, граница ответственности по системам и времени.

Эти же пункты стоит проверить в договоре с новым подрядчиком до подписания — вместе с остальными типичными ошибками ИТ-аутсорсинга.

Если передача идёт трудно

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

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

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

Что дальше

• Готовитесь к переходу. Соберите реестр ИТ-активов компании — без него приёмку не с чем сверять.
• Меняется не подрядчик, а сотрудник. Порядок отключения доступов при плановом увольнении — в материале увольнение сотрудника и отключение доступов.
• Не уверены, что копии рабочие. Проведите тестовое восстановление из резервной копии до, а не после переключения.
• Не знаете, что вообще у вас есть. Начните с вопроса о контроле: кому принадлежат домен, почта и сайт компании.

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

Процедуры и нормы, упомянутые в статье, проверены 5 сентября 2026 года.