Доработка сайта или новый сайт — выбор между двумя способами решить задачи бизнеса. Возраст проекта сам по себе не даёт ответа: существующий код может быть понятным и пригодным для развития, а новая разработка всё равно потребует переноса материалов, данных и связей с другими системами.
Решение стоит принимать после диагностики и сравнения двух вариантов с одинаковым результатом. Если в одном предложении учтена только новая форма, а в другом — новая платформа, каталог и интеграция, разница в цене пока ничего не говорит о выгоде.
Сначала определите, что должно измениться
Сформулируйте проблему через действие клиента или сотрудника. Например: клиент должен выбрать услугу и отправить фотографию оборудования; менеджер — получить обращение с нужными данными; редактор — самостоятельно обновить условия услуги. Затем запишите, как вы проверите каждый результат.
Разделите желаемые изменения по смыслу:
- Оформление и удобство: читаемость, расположение информации, навигация, мобильная форма.
- Функции и процессы: новые поля заявки, правила расчёта, поиск, обмен с CRM, работа редактора.
- Техническая основа: возможность безопасно обновлять проект, выпускать изменения и восстанавливать его после сбоя.
Если проблема в представлении информации, редизайн сайта может решить её без замены серверной части. Новый внешний вид и новая техническая основа — отдельные решения. Неудобный экран ещё не доказывает, что нужно переписывать весь сайт.
Что должна выяснить диагностика
Для выбора нужен ограниченный набор проверок, связанный с вашими задачами. Просите исполнителя показывать наблюдения и последствия, а не только оценку «код хороший» или «код плохой».
Можно ли воспроизвести проект? Есть ли исходники, перечень зависимостей и понятный порядок запуска? Удаётся ли развернуть рабочую копию, проверить изменение и выпустить его? Если доступен лишь работающий сайт без исходников, сначала выясните, можно ли получить их у прежнего исполнителя. Новая разработка не возвращает автоматически утраченные доступы.
Где проходит граница изменения? Добавление поля может затронуть форму, сохранение заявки, уведомление и CRM. Если эти части понятны и проверяемы, задача остаётся ограниченной. Если изменение одной услуги затрагивает непредсказуемые участки каталога, нужна дополнительная проверка причин и вариантов исправления.
Можно ли поддерживать основу? Попросите перечень используемых технологий и зависимостей, их состояние и план обновления по официальной документации. Важен объём необходимых изменений и их совместимость с проектом. Само название платформы не заменяет такую оценку.
Что уже работает и должно сохраниться? Проверьте путь от страницы услуги до получения заявки, редактирование материалов, обмен с внешними системами. Для сайта с кабинетами или заказами добавьте соответствующие сценарии. Список проверок должен охватывать больше, чем доступность главной страницы.
Результат диагностики — список подтверждённых ограничений, работ и неизвестных с объяснением, как каждое из них влияет на выбор. Если неизвестное существенно для цены или переноса, оцените следующий шаг, который его прояснит, вместо обещания окончательной сметы.
Когда дорабатывать, а когда рассматривать новую основу
| Что обнаружено | Что это означает для решения |
|---|---|
| Нужный результат достигается изменением понятного участка; остальное работает и проверяется | Есть основание оценивать ограниченную доработку |
| Основные сценарии подходят бизнесу, но отдельный модуль мешает развитию | Стоит сравнить замену этого модуля с заменой всего проекта |
| Новые требования меняют модель данных и большинство ключевых сценариев | Новую основу имеет смысл оценить наряду с глубокой модернизацией |
| Для сохранения платформы нужны крупные взаимосвязанные изменения | Сравнивать нужно весь объём модернизации, включая проверки, с разработкой и переносом |
| Не хватает исходников, доступов или понятного способа извлечь данные | Это зависимость, которую нужно разрешить для обоих вариантов |
Поэтапная модернизация полезна, когда часть сайта можно изменить независимо и получить законченный результат. Например, обновить обработку заявок, сохранив страницы услуг. Но если старый и новый модули временно работают вместе, заранее определите, где хранятся актуальные данные и кто отвечает за обмен. Иначе промежуточное состояние может оказаться сложнее обоих конечных вариантов.
Новая основа оправдана не обещанием «современного сайта», а конкретными возможностями: какие требования она позволит выполнить, какие ограничения снимет и как будет поддерживаться. Старый проект при этом остаётся источником бизнес-правил, контента и данных, которые нельзя потерять при переписывании.
Сравните полную стоимость одинакового результата
Попросите два предложения по одному списку требований. Для каждого варианта отдельно обозначьте:
- изучение проекта и подготовку рабочего окружения;
- изменение или разработку функций, интерфейса и структуры данных;
- подготовку и перенос контента, записей и файлов;
- настройку интеграций, доступов и адресов страниц;
- проверки, переключение, обучение редакторов и сопровождение после запуска.
В предложении должны быть перечислены допущения и зависимости: например, кто предоставит выгрузку, кто согласует новые поля и кто изменит настройки CRM. Если нет доступа к системе, её подключение ещё нельзя считать полностью оценённым.
Попросите объяснить неопределённость по конкретным работам. Формулировка «потребуется пробный перенос, потому что неизвестен формат вложений» полезнее произвольного запаса на все риски. Так можно отдельно согласовать диагностику, получить результат и уточнить оставшийся объём.
Потраченные когда-то деньги не доказывают, что сайт следует сохранить любой ценой. Но и цена новой разработки не отражает всей стоимости замены. Сравнивайте будущие расходы, необходимые для согласованного результата, и последствия возможного сбоя: остановку приёма заявок, ручную обработку, исправление данных.
Что сохранить при любом варианте
Данные и их связи
Составьте перечень того, что должно остаться: страницы, изображения, файлы, заявки, товары, заказы, учётные записи — в зависимости от сайта. Для каждой группы определите источник, владельца и способ проверки. Решение об удалении ненужных записей согласуйте отдельно.
Одного совпадения количества записей недостаточно для приёмки. Проверьте связи: вложение относится к нужной заявке, товар — к нужной категории, заказ — к нужному клиенту. Если внутренние идентификаторы меняются, потребуется таблица соответствий, чтобы внешние системы продолжили узнавать свои записи.
До переключения выполните пробный перенос и согласуйте контрольные примеры. Рабочие данные и копии храните с ограниченным доступом; не передавайте их через публичные папки. Для проверок, которым реальные данные не нужны, используйте обезличенные или учебные записи.
Адреса страниц и поисковая структура
Новая платформа не обязывает менять адреса всех страниц. Если назначение страницы сохраняется, рассмотрите сохранение её URL. Если адрес меняется, подготовьте соответствие старой страницы новой и проверьте постоянное серверное перенаправление — обычно с кодом 301 или 308. Не направляйте все старые страницы на главную: пользователь должен попадать на соответствующий материал.
Обновите внутренние ссылки и карту сайта, проверьте канонические адреса и ограничения индексации. Для удалённого материала без замены отдельно определите корректный ответ сервера. При существенном переносе возможны колебания видимости в поиске; аккуратная миграция не является гарантией неизменных позиций.
Управление и доступы
Зафиксируйте, кто управляет доменом, хостингом, исходниками, почтой, аналитикой и внешними сервисами. Перенос файлов не переносит автоматически права на эти ресурсы.
Исполнителям выдавайте отдельные учётные записи с правами, необходимыми для задачи. Проверьте роли сотрудников на новой или изменённой системе: возможность войти ещё не означает право видеть все заявки или менять настройки. После завершения работ пересмотрите временные доступы и передайте владельцу порядок управления проектом.
Как перейти без потери новых обращений
Пока готовится новая версия, действующий сайт может продолжать принимать заявки и изменения от редакторов. Поэтому дата первой выгрузки не должна стать незаметной границей, после которой данные перестанут переноситься.
В плане переключения укажите, как перенесутся записи, появившиеся после пробной загрузки. Возможны короткая согласованная остановка записи или перенос изменений за промежуток между выгрузкой и запуском. Подход зависит от системы; исполнитель должен показать, как он проверит отсутствие пропусков и дублей.
Также назначьте ответственного за решение о возврате к прежней версии и перечислите условия возврата. Резервную копию нужно проверить восстановлением в отдельном окружении. Если после запуска новый сайт уже принял обращения, возврат старой базы может их потерять: предусмотрите сохранение и последующую сверку этих записей. Откат — отдельный сценарий работы с данными, а не только замена файлов.
Учебный пример: новая форма для мастерской
Это вымышленная ситуация для разбора решения, а не клиентский кейс. У мастерской ремонта оборудования есть страницы услуг, архив обращений и передача заявок в CRM. Нужна форма, в которой клиент выбирает тип оборудования и прикладывает фотографию; менеджер должен получать оба значения. Адреса услуг и старые обращения должны сохраниться.
Предположим, диагностика показала: исходники доступны, рабочая копия запускается, страницы услуг подходят бизнесу, изменение обработки заявок можно проверить отдельно. Для этого набора условий разумно оценить доработку формы и её обработчика. Перенос всего сайта не добавляет необходимой возможности сам по себе.
Зависимости задачи — правила приёма файлов, соответствующие поля CRM и решение о том, что происходит при её временной недоступности. В учебном задании согласован такой результат: обращение сохраняется на сайте со статусом ожидания передачи, а менеджер видит его и может продолжить обработку.
Критерии приёмки здесь конкретны:
- На телефоне клиент отправляет заявку с выбранным оборудованием и допустимой фотографией. Неподходящий файл отклоняется с понятным сообщением.
- При доступной CRM менеджер получает данные в согласованные поля и видит вложение.
- При временном сбое CRM сохранённое обращение остаётся доступным ответственному. После повторной передачи оно связано с тем же обращением.
- Прежние страницы услуг открываются по тем же адресам; старые заявки и их вложения доступны сотрудникам с нужными правами.
- Редактор обновляет услугу, а заказчик получает результат проверок и понятный порядок выпуска и восстановления изменений.
Если же выяснится, что новое обращение невозможно добавить без переделки общей модели данных и нескольких зависимых модулей, исходная оценка перестанет быть достаточной. Тогда сравнивают расширенную модернизацию и новую основу с одинаковыми критериями, включая перенос архива. Решение меняется вслед за подтверждённым объёмом работ, а не вслед за впечатлением от возраста сайта.
Что должно остаться у владельца после выбора
Достаточное основание для решения — согласованные требования, результаты диагностики, сравнение вариантов, список сохраняемых данных и адресов, план переключения и критерии приёмки. По ним должно быть понятно, почему выбранный путь решает задачу и какие условия ещё предстоит выполнить.
Для ограниченного изменения после диагностики можно обсудить доработку сайта. Студия Вебирус рассматривает чужие проекты после диагностики и не обещает работу с любой технологией. После выпуска изменений отдельно назначьте ответственных за работу с сайтом после запуска: приём обращений, контроль ошибок и дальнейшие задачи.
