Дорабатывать старый сайт или делать новый: как принять решение
Возраст сайта не определяет решение. Старую систему можно развивать годами, если она поддерживается, предсказуемо меняется и не создаёт неприемлемых рисков. И наоборот: относительно новый проект может требовать замены, если бизнес не контролирует код и данные, любое изменение вызывает регрессии, а платформа блокирует основные планы.
Сравнивать нужно три сценария: точечную доработку, рефакторинг проблемных частей и пересборку с миграцией. Правильный вариант — тот, который решает задачи бизнеса с приемлемой стоимостью владения и риском перехода.
Разведите три разных типа работ
Доработка меняет отдельную функцию или интерфейс, сохраняя основу. Это подходящий путь, когда проблема локальна: новая форма, один шаблон, интеграция или улучшение мобильного сценария.
Рефакторинг меняет внутреннее устройство без обязательной полной замены продукта. Команда может обновить runtime, выделить проблемный модуль, стандартизировать развёртывание или покрыть критический путь тестами. Пользовательская часть при этом меняется не всегда.
Пересборка создаёт новую основу и переносит в неё нужные данные, URL, интеграции и процессы. Это не просто новый дизайн. В смету входят анализ старой системы, миграция, параллельное тестирование, запуск и период стабилизации.
Ошибка возникает, когда эти работы называют одним словом «редизайн». Интерфейс может быть устаревшим при здоровой архитектуре, а современный внешний вид — скрывать неподдерживаемый стек.
Проверьте техническую жизнеспособность
Составьте инвентаризацию CMS, языка и runtime, плагинов, библиотек, базы данных, сервера и внешних интеграций. Для каждого компонента нужны текущая версия, статус поддержки, способ обновления и владелец.
OWASP Top 10:2025 относит к рискам ситуацию, когда организация не отслеживает версии прямых и транзитивных зависимостей либо использует неподдерживаемое и не обновляемое ПО. Это не означает, что найденный старый компонент автоматически требует полной пересборки. Он означает, что риск нужно назвать и выбрать управляемый путь обновления.
Для PHP есть официальный календарь поддерживаемых версий. Подобные даты позволяют заменить спор «сайт старый» проверяемым вопросом: получает ли конкретная ветка исправления и можно ли безопасно перейти на поддерживаемую.
Проверьте также:
- доступны ли исходный код, репозиторий, база, домен и хостинг;
- существует ли тестовое окружение;
- можно ли повторить выпуск без ручной магии;
- восстанавливается ли система из резервной копии;
- документированы ли интеграции и фоновые задания;
- может ли другой специалист продолжить работу;
- можно ли экспортировать контент и данные без потери структуры.
Измерьте, насколько система мешает бизнесу
Технический долг становится управленческой проблемой, когда влияет на срок, стоимость, риск или доступность изменений. Возьмите несколько типовых задач за последний год и сравните план с фактом: сколько ушло на анализ, реализацию, исправление регрессий и выпуск.
| Сигнал | Локальная проблема | Системная проблема |
|---|---|---|
| Скорость изменений | один сложный модуль | почти каждая задача требует изучения всей системы |
| Регрессии | редкие и воспроизводимые | изменения регулярно ломают несвязанные участки |
| Зависимость от людей | знания распределены | выпуск возможен только с одним специалистом |
| Обновления | есть понятный план | обновлять страшно или фактически невозможно |
| Данные | экспортируются | закрыты в платформе или неизвестной структуре |
| Roadmap | большинство задач выполнимо | ключевые функции блокирует архитектура |
Не оценивайте сайт только количеством ошибок в коде. Для руководителя важнее «налог на изменение»: дополнительное время, которое текущее состояние добавляет к каждой бизнес-задаче.
Сравните стоимость владения, а не одну смету
Для каждого варианта выберите одинаковый горизонт планирования и запишите затраты без фиктивной точности.
Сохранение и доработка: регулярная поддержка, инциденты, обязательные обновления, более дорогие изменения, простои, зависимость от подрядчика и стоимость задержанного roadmap.
Рефакторинг: технический аудит, обновление основы, тесты, документация, постепенная замена модулей, временная параллельная работа старых и новых частей.
Пересборка: аналитика, проектирование, разработка, перенос контента и данных, интеграции, SEO-миграция, QA, инфраструктура, обучение и стабилизация после запуска.
Универсального порога, после которого пересборка всегда выгоднее, нет. Исследования CMU Software Engineering Institute описывают технический долг через будущую стоимость прежних компромиссов и необходимость управлять им явно, а не через единую формулу для всех систем: обзор модели technical debt.
Учтите SEO, аналитику и интеграции до решения
Сильный органический трафик, большое число индексируемых страниц, сложная CRM-связка или каталог с обменом данными повышают стоимость и риск пересборки. Это аргумент не против нового сайта, а за полноценную миграционную часть проекта.
Если меняются URL, Яндекс рекомендует настраивать со старых адресов серверные 301-редиректы на соответствующие новые страницы. До оценки нового решения составьте список URL, которые получают показы, трафик, заявки и внешние ссылки. Проверьте, можно ли сохранить их без изменения.
Отдельно опишите путь формы, звонка и заказа. Новая система должна не просто «интегрироваться с CRM», а сохранить нужные поля источника, правила создания лидов, защиту от дублей и возврат статусов продаж в аналитику.
Когда выбран вариант пересборки, используйте отдельный план перезапуска без потери SEO и заявок.
Матрица выбора
| Состояние | Доработка | Рефакторинг | Пересборка |
|---|---|---|---|
| Стек поддерживается, проблема локальна | основной вариант | избыточно | обычно избыточно |
| Интерфейс устарел, данные и backend здоровы | новый UI на текущей основе | при необходимости | редко |
| Несколько изолированных проблемных модулей | временно | основной вариант | сравнить по стоимости |
| Большинство задач блокирует архитектура | дорого и рискованно | возможно поэтапно | серьёзный кандидат |
| Основа не поддерживается, обновление затрагивает всё | слабый вариант | зависит от пути обновления | вероятный вариант |
| Нет контроля над кодом и данными | высокий риск | высокий риск | часто рационально с планом выхода |
| Сильный SEO-актив и критичные интеграции | безопасно для локальных задач | часто позволяет снизить риск | только с полной миграцией |
| Система стабильна и почти не меняется | обычно достаточно | только по рискам | может не окупиться |
Это матрица принятия решения BTD.TEAM, а не отраслевой стандарт. Заполнять её нужно фактами конкретного проекта.
Красные флаги пересборки и доработки
Пересборка опасна, если нет владельца миграции, перечня URL, схемы данных, плана тестирования и возможности временно сохранить старую систему. Новый код сам по себе не устраняет технический долг: без документации, обновлений и воспроизводимого выпуска он быстро создаст ту же зависимость в другой оболочке.
Бесконечная доработка опасна, если каждый релиз требует аварийного режима, критические компоненты не обновляются, стоимость изменений растёт, а бизнес-roadmap годами уступает исправлению основы. Уже потраченные деньги не делают этот путь выгодным — сравнивать нужно будущие расходы и риски.
Как принять решение на аудите
Соберите техническую инвентаризацию, историю изменений и инцидентов, backlog бизнеса, SEO-карту, интеграции и стоимость поддержки. Затем для каждого сценария зафиксируйте объём, ограничения, риск миграции и условия, при которых решение перестаёт быть разумным.
Выход аудита — не вердикт «всё переписать», а обоснованный выбор: что оставить, что изолированно исправить, что заменить и как защитить продажи при переходе. Если нужно сравнить сценарии на данных вашего проекта, обсудите технический и бизнес-аудит с BTD.TEAM.
