Сколько стоит поддержка легаси на PHP 7.4 в 2026 году (и почему мы его не трогаем)
Март 2026. Совещание у собственника. На экране открыт отчёт по уязвимостям. Одна строка красным: PHP 7.4. End of life — ноябрь 2022. Уже четвёртый год без патчей. Вопрос простой: «Сколько это нам стоит и когда вы наконец перепишете?»
Я ответил цифрами. Не «нужно модернизировать», а сколько денег, часов и нервов уходит прямо сейчас. И почему переписывать мы пока не будем.
Контекст: что у нас было
Компания — логистика, 90 человек в офисе + 40 на складах. Ядро бизнеса — внутренняя система заказов, складского учёта и интеграции с перевозчиками. Написана в 2016–2018 годах на PHP 7.2, потом кое-как дотянули до 7.4. Фреймворк — самописный, поверх Yii 1.1. База — MySQL 5.7. Фронт — jQuery и куча легаси-JS.
Система живая. Каждый день через неё проходит 2–3 тысячи заказов. Простой на два часа — это уже ощутимые деньги. Полный отказ — катастрофа.
Серверы стоят на dedicated в российском ДЦ. PHP работает через php-fpm, Apache. Никакого Docker, никакого Kubernetes. Просто железо и конфиги, которые правили руками последние восемь лет.
Сколько реально стоит поддержка в 2026 году
Я посчитал за полный 2025 год и экстраполировал на 2026. Вот таблица.
Статья расходовСумма в год (руб)Что входитМониторинг и алерты180 000Uptime Kuma + Telegram-боты + отдельный сервер под логиWAF и защита240 000Cloudflare + самописные правила + CrowdSec на уровне сервераРучные патчи и workaround420 00035–40 часов сисадмина/разработчика в месяц × ставкаРезервное копирование и восстановление95 000BorgBackup + тесты восстановления раз в кварталДополнительный сервер «на всякий»160 000Холодный стенд для быстрого откатаСтраховка и аудит безопасности300 000Внешний пентест раз в год + внутренний разбор CVEsПотерянное время разработчиков510 000Обходы ограничений, костыли, поддержка старого кодаИтого1 905 000
Почти два миллиона в год. Только на то, чтобы старый PHP не лёг и не был взломан.
Самая большая статья — не железо и не софт. Это время людей. Каждый раз, когда выходит новый CVE по OpenSSL, curl или самому PHP, мы не ставим патч. Мы пишем костыль, закрываем порт, ограничиваем доступ, добавляем правило в WAF. Это часы.
Плюс постоянный страх. Разработчики, которые ещё помнят этот код, уже не junior. Их ставка выросла. Новых нанимать на легаси почти невозможно — нормальные люди смотрят на PHP 7.4 и сразу отказываются.
Что мы пробовали
В 2023–2024 годах мы дважды пытались двигаться.
Первый раз — «давайте хотя бы поднимем до PHP 8.1». Оценка: 4–5 человеко-месяцев только на то, чтобы код начал работать. Потом ещё столько же на тесты. Итог — отложили.
Второй раз — частичная миграция. Взяли один модуль (отчёты) и переписали на Symfony 6 + PHP 8.3. Получилось. Но интеграция с основным ядром превратилась в ад. Два месяца ушло только на то, чтобы данные ходили туда-сюда без потери. В итоге модуль живёт отдельно, а ядро как было на 7.4, так и осталось.
Самый неприятный момент случился осенью 2025. Нашли эксплуатацию старой уязвимости в одном из компонентов (через старый Guzzle и кривую обработку XML). Не до конца, но близко. Два дня сидели на ушах, перекрывали доступ, чистили. После этого решили: пока система критична для бизнеса — трогать ядро нельзя.
Как говорится, пока толстый сохнет, худой сдохнет. Мы выбрали не сдохнуть.
Что реально работает и почему мы не трогаем ядро
Мы не «игнорируем проблему». Мы её локализовали.
- Максимальная изоляция.Система сидит в отдельном VLAN. Снаружи торчит только через Nginx reverse proxy с жёсткими правилами. Всё, что можно, закрыто по IP. Подробнее про такую схему мы уже разбирали, когда настраивали DMZ на MikroTik.
- Мониторинг всего, что шевелится.Uptime Kuma смотрит не только доступность, но и время ответа критических эндпоинтов. Любое отклонение — сразу в Telegram. Плюс логи через отдельный пайплайн. Если интересно, как быстро поднимается нормальный алертинг — вот статья про Uptime Kuma.
- CrowdSec вместо классического Fail2Ban.Fail2Ban на старом PHP уже почти бесполезен — атаки стали умнее. CrowdSec даёт сообщество сигнатур и нормальную реакцию. Мы перешли в прошлом году и не пожалели. Если думаете, стоит ли менять — вот сравнение.
- Резервное копирование, которое реально восстанавливается.BorgBackup + шифрование + проверка раз в квартал. Не «бэкап есть», а «мы его поднимали на чистом сервере и оно работает».
- Жёсткий контроль доступа.Никаких прямых SSH с интернета. Только через jump-хост и ключи. Разработчики работают через VPN. Права в самой системе урезаны до минимума.
Ядро мы не трогаем по одной простой причине: цена ошибки выше, чем цена поддержки.
Переписать с нуля — это 8–12 человеко-месяцев сильных разработчиков. При текущих ставках это 4–6 миллионов только на зарплату. Плюс простой, плюс риск потерять бизнес-логику, которая за восемь лет обросла кучей неявных правил. Плюс обучение всех, кто работает с системой.
А поддержка текущего состояния — почти два миллиона в год. И она предсказуема.
Где мы всё-таки двигаемся
Мы не сидим на месте. Просто двигаемся не туда, куда обычно советуют.
- Новый функционал пишем уже на PHP 8.3 в отдельных сервисах. Общаемся через очереди и API.
- Старые куски, которые можно выкинуть безболезненно, постепенно вырезаем.
- Всё, что касается отчётов и аналитики, уже живёт отдельно.
- Инфраструктуру вокруг легаси приводим в порядок: мониторинг, бэкапы, сеть, доступы.
По сути, мы делаем то, что в нормальных компаниях называют «strangler pattern». Только без громких слов. Просто постепенно душим старое, пока оно ещё дышит.
Что бы я сделал иначе
Если бы можно было вернуться в 2022–2023, я бы начал выносить куски раньше. Не ждал бы, пока EOL станет совсем красным. И сразу закладывал бы нормальную изоляцию и мониторинг, а не «потом как-нибудь».
Сейчас уже поздно геройствовать. Сейчас нужно считать деньги и риски.
Главный вывод
Поддержка PHP 7.4 в 2026 году — это не «технический долг», который надо срочно закрыть. Это статья расходов. Конкретная, измеримая, примерно два миллиона в год для нашей системы.
Иногда выгоднее платить эту статью, чем устраивать революцию. Особенно когда система критична и на ней едут реальные деньги.
Мы не трогаем ядро не потому, что ленимся. А потому что посчитали и поняли: сейчас это самый дешёвый и безопасный вариант.
А у вас как? Сколько у вас ещё живёт систем, которые формально уже нельзя трогать, но бизнес без них не работает? Пишите в комментариях — интересно сравнить цифры.
Больше про инфраструктуру без воды — в блоге IT-Аптека и в Telegram-канале.