Веб-студия сделала сайт и держит его у себя: как забрать проект

MAATRIX

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

Почему студии по умолчанию хостят у себя

Модель «разработка плюс хостинг в одном пакете» возникла не случайно и не из желания привязать клиента к себе любой ценой — у неё понятная операционная логика с обеих сторон.

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

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

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

Чем эта ситуация отличается от зависшего на чужом аккаунте сервера

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

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

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

Что технически усложняет перенос: специфика студийной инфраструктуры

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

• Общие панели управления и кастомные скрипты деплоя. Вместо стандартного nginx/Apache с прозрачной конфигурацией — внутренняя система управления сайтами студии, где деплой, ssl-сертификаты и бэкапы завязаны на скрипты, нигде не документированные и не переносящиеся вместе с кодом.
• Общая база данных на несколько клиентов. Ради экономии ресурсов несколько сайтов студии нередко используют один сервер MySQL/PostgreSQL с разделением по базам или схемам — выгрузить «только вашу часть» возможно, но требует аккуратности, которой при спешке легко не хватает.
• Нестандартные версии окружения. Студия годами держит определённую версию PHP, Node.js или фреймворка, потому что на ней завязаны десятки других её проектов. При переезде на современный независимый хостинг код может неожиданно не завестись без правок.
• Скрытые интеграции с внутренними сервисами студии. Общий SMTP-релей для писем, общее хранилище для файлов, общий CDN-аккаунт — то, что было «бесплатным приложением» к хостингу и что придётся поднимать отдельно на новом месте.
• Отсутствие письменной документации именно по вашему проекту — когда всё работает по внутреннему шаблону, который держат в голове инженеры студии, отдельного описания вашего сайта часто просто не существует.

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

Коммерческий интерес студии — и почему это обычно не конфликт

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

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

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

Как завести разговор со студией

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

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

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

Попросите конкретный план и сроки, а не общее согласие. «Хорошо, поможем» без даты — это не план. Зафиксируйте письменно (в переписке достаточно, не обязательно отдельным договором): что именно студия выгружает, к какому числу, кто на стороне студии отвечает за этот процесс.

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

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

Экспорт данных и техническая миграция

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

Что стоит запросить у студии как полный комплект для переезда:

• Полный архив файлов сайта — не только видимый код в git-репозитории, если он есть, но и загружаемые пользователями файлы, медиатеку, сгенерированный кэш, если от него зависит работа сайта.
• Дамп базы данных целиком, а не выборочно — с учётом того, что часть данных может физически жить в общей для нескольких клиентов базе, о чём стоит явно спросить студию.
• Список переменных окружения и внешних интеграций: SMTP для почты, ключи платёжных систем, сторонние API — без них код на новом сервере не заработает, даже если файлы и база перенесены идеально.
• Точные версии окружения, на которых сайт реально работает сейчас: версия PHP/Node.js/Python, версия СУБД, используемые расширения — расхождение версий на новом сервере чаще всего и оказывается причиной, почему «перенесённый» сайт работает не так, как раньше.
• Конфигурацию веб-сервера (nginx/Apache) в исходном виде, а не только описание «что настроено» — специфичные редиректы и правила легко забыть при ручном воссоздании.

Дальше — стандартная последовательность переезда на новый сервер, без принципиальных отличий от любой другой миграции: разворачиваете копию на независимой инфраструктуре, тестируете по IP или через файл hosts, не трогая рабочий домен, и только после полной проверки переключаете DNS. Подробный пошаговый план именно такого переезда — с тестированием до переключения трафика и правилами отката — разобран в статье «Перенос сайта на новый VPS без простоя»; общий чек-лист подготовки к миграции на новый сервер — в статье «Как составить план миграции на новый сервер». Оба материала написаны для общего случая переезда и полностью применимы здесь — разница только в том, что источником данных выступает инфраструктура студии, а не ваш собственный прежний сервер.

Базовый пример того, с чего обычно начинается перенос после получения архива от студии:

# распаковка полученного архива с файлами сайта
tar xzf site-export-from-studio.tar.gz -C /var/www/site/

# восстановление базы данных на новом сервере
mysql -u dbuser -p dbname < studio-db-dump.sql
# для PostgreSQL:
pg_restore -U dbuser -d dbname studio-db-dump.dump

# проверка версий окружения на новом сервере против того, что было у студии
php -v
node -v
mysql --version

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

Что стоит проговорить со студией на будущее — уже при заказе новой разработки

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

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

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

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

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

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

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