Что делать с legacy-проектом на старом PHP

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

При этом сама система может продолжать приносить пользу. Клиенты оформляют заказы, сотрудники работают в CRM, менеджеры ведут заявки, бизнес получает деньги. Поэтому вопрос звучит сложнее, чем «старый PHP плохой или хороший».

Обычно у компании есть три сценария:

• оставить систему как есть;
• обновить проект и постепенно отрефакторить;
• переписать продукт с нуля.

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

Почему legacy на PHP не всегда проблема

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

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

Если такую систему заменить без анализа, можно потерять не только старый код. Можно потерять поведение, к которому привыкли сотрудники и клиенты.

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

Когда можно оставить всё как есть

Иногда самый рациональный выбор — ничего радикально не менять.

Это подходит проектам, которые:

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

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

Но «оставить как есть» не равно «забыть». Даже спокойный legacy-проект нужно периодически проверять: резервные копии, мониторинг, доступы, сервер, документацию, базу данных, SSL, домены, критичные интеграции и возможность восстановления после сбоя.

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

Когда лучше обновлять и рефакторить

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

В такой ситуации выгоднее развивать существующий продукт поэтапно, чем останавливать всё ради полной замены.

Обычно работа включает:

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

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

Когда переписывание действительно оправдано

Иногда старая система действительно исчерпала ресурс. Рефакторинг в таком случае превращается в бесконечный ремонт, а каждый новый модуль только усиливает хаос.

Переписывание может быть оправдано, если:

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

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

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

Почему «перепишем всё» часто становится ловушкой

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

На практике такие проекты регулярно сталкиваются с одинаковыми проблемами.

Во-первых, первоначальная оценка почти всегда оказывается слишком оптимистичной. В старой системе много скрытой логики, которая открывается только во время разработки.

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

В-третьих, старую систему приходится поддерживать до запуска новой. Компания фактически оплачивает два продукта: один работает сейчас, второй ещё только создаётся.

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

Поэтому полная замена должна быть осознанным решением, а не эмоциональной реакцией на плохой код.

Какие риски несут старые версии PHP

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

У PHP есть официальный жизненный цикл: ветка получает активную поддержку, затем период исправлений критичных проблем безопасности, после чего переходит в end of life. На 9 июля 2026 года PHP 8.1, 8.0 и 7.4 уже находятся среди неподдерживаемых веток, а PHP 8.2 получает только security fixes до 31 декабря 2026 года.

Для бизнеса это означает несколько практических последствий.

Меньше обновлений безопасности

После окончания поддержки версия PHP больше не получает официальные исправления. Сама система может продолжать работать, но требования к защите инфраструктуры становятся выше.

Сложнее обновлять библиотеки

Новые версии пакетов постепенно прекращают поддержку старого PHP. Из-за этого сложнее внедрять интеграции, обновлять фреймворк и подключать современные инструменты.

Дороже сопровождение

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

Больше инфраструктурных ограничений

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

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

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

Как выбрать между поддержкой, обновлением и переписыванием

Перед решением полезно ответить на несколько вопросов:

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

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

Как проходит разумная модернизация legacy-проекта

Работа с legacy редко начинается с большого релиза. Безопаснее идти поэтапно.

Шаг 1. Технический аудит

Команда изучает архитектуру, версию PHP, зависимости, базу данных, интеграции, безопасность, производительность, инфраструктуру и критичные пользовательские сценарии.

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

Шаг 2. Карта рисков и приоритетов

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

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

Шаг 3. Подготовка окружения и резервного плана

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

Если этого нет, начинать рефакторинг рискованно.

Шаг 4. Обновление и рефакторинг критичных зон

Сначала улучшаются участки, которые мешают развитию или создают риск: старые зависимости, проблемные интеграции, узкие места базы данных, небезопасная обработка данных, модули с частыми ошибками.

Изменения лучше делать небольшими шагами, чтобы бизнес видел результат и команда могла контролировать качество.

Шаг 5. Решение о дальнейшей архитектуре

После первых этапов становится понятнее, стоит ли продолжать модернизацию, выделять отдельные сервисы, заменять модули или готовить новую систему.

Это уже не гадание. Решение опирается на состояние проекта и реальные ограничения.

Сценарии на практике

Сценарий 1. Оставить и контролировать

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

Сценарий 2. Обновить PHP и зависимости

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

Сценарий 3. Рефакторить проблемные модули

Подходит системам, где основная логика ценна, но отдельные части мешают развитию: корзина, каталог, интеграции, отчёты, личный кабинет, админка, обмен с CRM или 1С.

Сценарий 4. Переписывать поэтапно

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

Почему начинать стоит с аудита

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

Аудит показывает причины:

• какие части системы действительно устарели;
• где есть риски безопасности;
• какие версии PHP и зависимостей используются;
• какие модули сильнее всего мешают развитию;
• где нужны тесты;
• что можно обновить быстро;
• какие изменения лучше отложить;
• когда переписывание экономически оправдано.

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

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

FAQ

Нужно ли срочно переписывать проект на старом PHP?

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

Можно ли оставить legacy-проект без изменений?

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

Чем опасны старые версии PHP?

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

Что дешевле: рефакторинг или переписывание?

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

Как снизить риск при обновлении legacy-проекта?

Начать с аудита, проверить бэкапы, подготовить staging, описать критичные сценарии, добавить тесты там, где они действительно нужны, обновлять систему поэтапно и не менять всё одновременно.

Когда пора готовить новую систему?

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

Что делает Origami

Origami работает с веб-проектами с 2008 года и помогает компаниям разбираться с наследуемыми PHP-системами: аудитом, поддержкой, обновлением, рефакторингом и развитием.

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

Если старый PHP-проект работает, но развитие стало дорогим и тревожным, начните с технического аудита. Это самый короткий путь от ощущений к нормальному плану действий.

Обсудить задачу с Origami