Передача проекта другому разработчику: как забрать сайт или бота без потерь

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

С чего начать смену подрядчика

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

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

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

Чек-лист доступов

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

Какую документацию запросить

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

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

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

Аудит кода и инфраструктуры

Прежде чем брать проект в работу и обещать сроки, новый исполнитель должен понять, что ему достаётся. Аудит отвечает на простые вопросы: можно ли это развивать, сколько будет стоить поддержка и где лежат мины. Что мы проверяем:

1. Собирается ли проект из репозитория. Бывает, что код на сервере отличается от кода в репозитории, потому что правки вносили прямо на живом сайте.
2. Возраст зависимостей. Устаревшие версии фреймворка и библиотек — это уязвимости и трудные обновления в будущем.
3. Секреты в коде. Пароли и токены, записанные прямо в репозиторий, нужно вынести в конфигурацию и перевыпустить.
4. Бэкапы. Есть ли они, где хранятся и можно ли из них реально восстановиться.
5. Архитектура и качество кода. Насколько сложно вносить изменения, есть ли тесты, нет ли критичной логики, которую никто не понимает.
6. Безопасность. Проверка входных данных, права в админке, проверка подписи данных Mini App на сервере — о ней подробно в статье про разработку Telegram Mini App.

Итог аудита — отчёт с рисками и рекомендацией: развивать как есть, постепенно переписывать отдельные части или, в редких случаях, делать заново. «Код чужой, поэтому перепишем» — плохая причина. Хорошая — когда исправлять дороже, чем сделать новое.

Типичные риски при смене подрядчика

• Домен или сервер оформлен на разработчика. Формально это его аккаунт, и без его участия переоформление затянется.
• Кода нет в репозитории. Актуальная версия существует только на сервере или на ноутбуке исполнителя.
• Платные компоненты на чужой лицензии. Тема, плагин или сервис куплены на аккаунт разработчика и перестанут обновляться.
• Скрытые зависимости. Письма уходят через личный почтовый сервис исполнителя, файлы лежат в его облачном хранилище.
• Потеря знаний. Почему сделано именно так, знает только автор, а комментариев в коде нет.
• Незакрытые расчёты. Неоплаченный счёт или спор превращают передачу в переговоры, поэтому финансовые вопросы лучше закрыть до запроса доступов.

План перехода без простоя

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

1. Получаем доступы и делаем полную копию: код, база, файлы, конфигурация.
2. Разворачиваем копию на тестовом окружении и убеждаемся, что она работает так же, как боевая версия.
3. Если нужен переезд на другой сервер, заранее уменьшаем время жизни DNS-записей, чтобы переключение прошло быстро.
4. Выбираем время с минимальной нагрузкой, переносим свежие данные и переключаем домен.
5. Для бота указываем новый адрес вебхука и проверяем, что обновления приходят.
6. Меняем пароли, перевыпускаем токены и ключи, к которым был доступ у прежней команды.
7. Одну-две недели внимательно следим за мониторингом и логами и до конца этого срока не удаляем старый сервер.

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

Кому принадлежат код и права

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

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

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

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

Частые вопросы

Обсудим проект

Нужна похожая разработка?

Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.

Ваше имя Способ связиTelegramVKMAXТелефонПочта

Контакт

Отправить заявкуНаписать напрямую

Источники

• Telegram Bot API

Опубликовано 12 октября 2026 г. · Обновлено 12 октября 2026 г.