Vendor lock-in в IT: как защитить код, доступы и возможность сменить подрядчика

Система может исправно работать несколько лет — до момента, когда бизнесу понадобится другой подрядчик. Именно тогда иногда выясняется, что репозиторий находится в чужом аккаунте, хостинг оплачивает разработчик, доступ к базе данных есть только у одного человека, резервные копии никто не проверял, а новый инженер не способен запустить проект без помощи прежней команды.

Это и есть практическая сторона vendor lock-in: компания зависит от конкретного поставщика настолько сильно, что сменить его технически, финансово или организационно гораздо сложнее, чем должно быть.

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

Хорошо организованный IT-проект не обязан быть независимым от всех поставщиков. Он должен быть переносимым настолько, чтобы смена подрядчика оставалась управленческим решением, а не угрозой для работы компании.

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

Что такое vendor lock-in простыми словами

Vendor lock-in — это ситуация, когда отказаться от поставщика можно формально, но на практике слишком дорого, долго или рискованно.

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

Для владельца бизнеса определение проще.

Если завтра текущий разработчик перестанет отвечать на сообщения, сможете ли вы передать систему другой команде и продолжить работу без восстановления проекта практически с нуля?

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

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

Результат для бизнеса от этого не меняется.

Главная ошибка: считать, что владение системой равно контролю над системой

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

Есть несколько разных уровней контроля.

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

Технический контроль означает, что компания имеет необходимые доступы к коду, инфраструктуре, данным, доменам и сервисам.

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

Наконец, экономический контроль означает, что стоимость перехода к другому поставщику известна и остается приемлемой.

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

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

Как понять, что бизнес уже зависит от IT-подрядчика

Один отдельный признак еще не означает критический vendor lock-in. Опаснее их сочетание.

Проверить стоит следующие ситуации:

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

Особенно опасна ситуация, когда руководство узнает обо всем этом уже после возникновения конфликта с поставщиком. Тогда обычная передача проекта превращается в аварийную миграцию.

Что бизнес действительно должен контролировать

Задача собственника — не хранить все пароли лично и не управлять сервером. Компания должна оставаться владельцем критических точек контроля, а подрядчики должны получать необходимые им права для работы.

Практически это можно проверить по следующей матрице.

Здесь важен именно последний столбец.

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

Контроль должен быть проверяемым.

Почему одного договора недостаточно

Договор необходим, но он не заменяет технической передачи.

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

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

Для IT-проекта разумно заранее определить как минимум:

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

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

Handover нужно проектировать до того, как он понадобится

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

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

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

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

Тогда смена подрядчика перестает быть отдельным проектом по поиску потерянной информации.

Репозиторий должен принадлежать бизнесу, а не конкретному разработчику

Одна из самых простых мер против vendor lock-in — создавать GitHub, GitLab, Bitbucket или другую систему хранения исходного кода в пространстве, контролируемом заказчиком.

Это не значит, что владелец компании должен заниматься Git. Ему нужен административный контроль над организацией или аккаунтом.

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

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

Инфраструктура важнее, чем кажется

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

Для небольшого проекта совершенно нормально, если подрядчик управляет инфраструктурой. Иногда это проще и дешевле, чем создавать внутреннюю компетенцию.

Но управление и владение — разные вещи.

Компания должна понимать:

• на чьем аккаунте находится инфраструктура;
• кто оплачивает услуги;
• где лежат данные;
• кто имеет административные права;
• можно ли перенести систему;
• что произойдет после прекращения договора;
• сколько технической работы потребует перенос.

Если инфраструктура остается на аккаунте подрядчика, должен существовать понятный и проверяемый сценарий выхода.

Для части облачных и других услуг обработки данных дополнительное значение имеет EU Data Act. Регламент применяется с 12 сентября 2025 года и содержит правила, направленные на устранение технических, договорных и организационных препятствий при смене поставщика таких услуг. В частности, он предусматривает договорные условия, связанные с переходом к другому поставщику, переносом экспортируемых данных и цифровых активов, поддержкой перехода и непрерывностью работы. Конкретная применимость этих положений зависит от характера услуги и договора.

Законодательство помогает создать рамки. Оно не заменяет нормальную архитектуру, документацию и контроль аккаунтов.

Резервная копия не считается защитой, пока ее нельзя восстановить

Компании часто узнают о проблемах с бэкапами в худший момент.

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

Поэтому правильный вопрос звучит не «есть ли у нас резервные копии?», а:

«Когда последний раз кто-то успешно восстановил систему из резервной копии?»

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

Документация должна позволять продолжить работу, а не просто существовать

Нет смысла требовать сотни страниц документации, которые никто не обновляет.

Для большинства бизнес-систем полезнее небольшой набор документов, соответствующих реальному состоянию проекта:

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

Качество документации лучше измерять не объемом, а простой проверкой: способен ли инженер, незнакомый с проектом, выполнить основные операции без постоянных звонков предыдущему разработчику.

Что делать с персональными данными при смене подрядчика

Если подрядчик обрабатывает персональные данные от имени компании и выступает обработчиком в смысле GDPR, вопрос завершения сотрудничества касается не только доступа к системе.

Статья 28 GDPR предусматривает, что после окончания оказания услуг обработчик — в зависимости от решения администратора данных — возвращает или удаляет персональные данные и удаляет существующие копии, если законодательство не требует их хранения.

На практике это означает, что процесс выхода должен учитывать:

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

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

Vendor lock-in не всегда нужно устранять любой ценой

Полная технологическая независимость тоже стоит денег.

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

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

Правильный вопрос поэтому не «есть ли зависимость?».

Лучше спросить:

Понимаем ли мы эту зависимость, какую выгоду получаем взамен и что будет стоить выход?

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

Если никто не способен оценить последствия ухода поставщика — это уже проблема управления.

Как проверить текущую систему до того, как возникнет конфликт

Не нужно ждать расторжения договора. Состояние проекта можно проверить в спокойной обстановке.

Попросите специалиста, который не работает с системой каждый день, выполнить несколько реальных действий:

1. Получить код из репозитория.
2. Получить необходимые зависимости и конфигурацию.
3. Запустить проект в тестовой среде.
4. Восстановить копию базы данных.
5. Определить все критические интеграции и внешние сервисы.
6. Объяснить, где находятся production-инфраструктура и резервные копии.
7. Выполнить тестовое развертывание небольшой безопасной версии.

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

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

Как безопасно сменить IT-подрядчика

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

Если нет угрозы безопасности, переход лучше организовывать последовательно.

Сначала составьте полный инвентарь активов и доступов. Затем получите независимые копии кода и данных, перенесите критические аккаунты под контроль компании и убедитесь, что резервные копии восстанавливаются.

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

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

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

Как выглядит хороший результат передачи проекта

Успешный handover — это не папка с файлами и письмо «все передали».

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

У бизнеса при этом остаются:

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

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

Если это возможно, передача действительно состоялась.

Когда можно разобраться самостоятельно

Для небольшого сайта или простой системы часто достаточно внутренней проверки.

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

Сложность растет, когда система:

• критична для ежедневной работы компании;
• разрабатывалась много лет;
• имеет несколько окружений и баз данных;
• связана с CRM, ERP, платежами или другими внешними системами;
• обрабатывает значительный объем персональных или чувствительных бизнес-данных;
• почти не документирована;
• обслуживается одним человеком;
• находится на инфраструктуре, которую компания фактически не контролирует.

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

Если компания только планирует собственную систему, контроль передачи стоит заложить еще в архитектуру и правила проекта. Именно поэтому при разработке веб-систем вопрос «как мы когда-нибудь уйдем от текущей команды?» полезно задавать еще до первой строки production-кода.

Что здесь действительно защищает бизнес

Сильная защита от vendor lock-in не означает недоверие к подрядчику.

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

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

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

Growth Insider может помочь провести такую техническую диагностику и определить, что действительно нужно передать, исправить или закрепить до смены команды. Обсудить текущую ситуацию.