# Как сменить разработчика и передать проект без потери доступов

Источник: https://quicklanding.ru/knowledge/website-vendor-change/

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

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

## Составьте карту проекта

![Обсуждение работы в офисе](/assets/images/knowledge/website-vendor-change.webp)

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

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

## Получите рабочую копию и документацию

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

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

## Проведите приёмку до больших изменений

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

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

## Уберите ненужные доступы по завершении

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

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

## Зафиксируйте момент передачи

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

## Связанные материалы

[Кто отвечает за тексты, дизайн и доступы при разработке сайта](/knowledge/website-project-roles/)

[Поддержка WordPress: что включить в регулярные работы](/knowledge/wordpress-maintenance-scope/)

## Документация для проверки

[Постоянные и временные перенаправления: Google Search Central](https://developers.google.com/search/docs/crawling-indexing/301-redirects)

Ссылки на документацию проверены 8 октября 2026 года. Названия настроек и возможности сервисов могут меняться; перед внедрением сверяйте актуальные условия.

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

### Обязательно ли переносить сайт на другой хостинг?

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

### Когда менять пароли и ключи интеграций?

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

### Какая копия сайта считается достаточной?

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

Автор: Владимир Николаев