Обновление старого сайта на Laravel или PHP в 2026 году

Реальные затраты, реальные инструменты и вопрос, который никто не задаёт первым

Большинство сайтов не ломаются в тот день, когда их программное обеспечение перестаёт получать исправления безопасности. Они продолжают работать. Заявки приходят. Страницы открываются. Форма обратной связи на месте. Владелец открывает сайт и видит ровно то, что ожидает увидеть.

Именно в этом опасность.

На главной не появляется надпись: ЭТОТ САЙТ РАБОТАЕТ НА ПРОГРАММАХ 2018 ГОДА. Ничего не краснеет, когда у фреймворка заканчивается поддержка. Никто не получает уведомления, что пакет, на котором держится половина админки, давно заброшен. Сайт может выглядеть совершенно здоровым, пока технологии под ним становится всё сложнее поддерживать, защищать и менять.

Владельцы редко бывают беспечными. Обычно сайт просто ни разу не дал им повода заглянуть внутрь.

Поэтому настоящий вопрос в 2026 году не в том, открывается ли старый сайт на Laravel или PHP. Конечно, открывается. Вопрос в том, какая часть бизнеса сегодня зависит от программ, на которые годами никто внимательно не смотрел.

Коротко

• Больше трети PHP-сайтов всё ещё работают на PHP 7 или PHP 5, которые больше не получают исправлений безопасности (W3Techs, сентябрь 2026).
• Laravel обновляется только по одной мажорной версии за раз, и PHP должен обновляться вместе с ним: Laravel 13 требует PHP 8.3 или новее.
• Автоматические инструменты берут на себя механические шаги, но основные затраты уходят на тестирование, заброшенные пакеты и тихие поломки вроде недоставленных писем.
• Честную цену обновления старого сайта можно назвать только после аудита; о переделке с нуля стоит говорить, когда обновление приближается к 60% её стоимости.
• Обновление часто вскрывает проблемы за пределами кода, например хостинг, который закрывает сайт от ИИ-роботов, и они заслуживают не меньшего внимания.

ИЛЛЮЗИЯ

Сайт, который выглядел нормально

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

Недавно мы смотрели сайт, у владельца которого не было видимых причин для беспокойства. Страницы работали. Бизнес пользовался сайтом каждый день. А под капотом сервер работал на PHP 5.6. Хостинг-аккаунт контролировал человек со стороны. Служебные скрипты лежали в открытом доступе, посетители могли видеть ошибки PHP, а письма с формы заявок почтовый сервер молча отклонял.

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

В этом разница между устаревшим софтом и сломанным сайтом. Сломанный сайт заявляет о себе сам. Устаревший продолжает делать свою работу и тихо становится всё дороже в содержании.

Исправление в тот раз не потребовало героической переделки. Это был аккуратный переезд на хостинг, который контролирует владелец, обновление до PHP 8.2, закрытие открытых путей и восстановление доставки почты. Работа заняла два вечера.

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

ВИЗУАЛЬНЫЙ ВОЗРАСТ

Молодой снаружи, старый внутри

Это различие удивительно часто теряется.

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

Визуальный и технический возраст это разные вещи. Дизайн-ревью не скажет, здоров ли сайт технически. Оно скажет, что страница выглядит старой. На чём на самом деле работает бизнес, скажет только аудит.

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

ЦИФРЫ

Насколько далеко вы отстали?

PHP по-прежнему работает на большей части интернета. По данным W3Techs на сентябрь 2026 года, его используют 70,2% сайтов с известным серверным языком. Но картина по версиям неровная: 63,4% PHP-сайтов работают на PHP 8, а 28,7% всё ещё на PHP 7 и 7,9% на PHP 5.

PHP 7 и PHP 5 больше не получают исправлений безопасности. Но и PHP 8 сам по себе ничего не гарантирует, потому что у каждой ветки свой срок поддержки:

• PHP 7.4: исправления безопасности закончились 28 ноября 2022
• PHP 8.1: закончились 31 декабря 2025
• PHP 8.2: до 31 декабря 2026
• PHP 8.3: до 31 декабря 2027
• PHP 8.4: до 31 декабря 2028
• PHP 8.5: до 31 декабря 2029

Laravel живёт по ещё более короткому циклу. Каждая версия получает 18 месяцев исправлений ошибок и два года исправлений безопасности. С весны 2026 года поддерживаются только Laravel 12 и 13, а Laravel 11 потерял поддержку безопасности 12 марта 2026 года.

Эти даты интересны не потому, что интересны номера версий. Они важны потому, что вместе с ними движется вся экосистема.

ДОРОГА

Дорога не будет ждать

Компания может решить остаться на старой платформе ещё на год. Технически это возможно. Меняется всё вокруг.

И большая часть рынка уже решила двигаться. В отчёте Zend 2026 PHP Landscape Report 68% команд на PHP завершили переход за последние 12 месяцев, а у 67% он запланирован на ближайшие 12 месяцев. Не планируют ничего только 21%.

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

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

Поэтому цена устаревшей системы это не только цена исправления старого фреймворка. Это растущая цена того, что вы становитесь исключением, и об этом мы писали в статье о скрытой цене стояния на месте.

КОНЕЦ ПОДДЕРЖКИ

Когда поддержка заканчивается

Обычно в сам день окончания поддержки не происходит ничего драматичного. Поэтому эту дату так легко пропустить. Риск растёт тихо:

• Безопасность. Уязвимости продолжают находить, но исправления для неподдерживаемой версии уже не выходят.
• Хостинг. Рано или поздно хостинг отключает старые версии PHP, и иногда переезжать приходится под давлением.
• Интеграции. Новые платёжные модули, коннекторы CRM и плагины отказываются устанавливаться на старую платформу.
• Люди. Всё меньше разработчиков хотят брать неподдерживаемые системы, а те, кто берёт, закладывают риск в цену.

Темп на стороне безопасности стоит знать. Patchstack насчитал 11 334 новые уязвимости в экосистеме WordPress за 2025 год, при этом медианное время до первой эксплуатации самых атакуемых уязвимостей около пяти часов. Не каждый PHP-сайт в той же зоне риска. Но это показывает, как быстро меняется среда, пока неподдерживаемая система стоит на месте.

ИИ И ИНТЕГРАЦИИ

Не только безопасность

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

ИИ-ассистент. Поиск, который понимает вопросы, а не точные фразы. CRM, которая общается с сайтом. Новая платёжная система. Личный кабинет клиента. Интеграция, которую старая система не тянет.

Это меняет разговор. Если клиент просит добавить ИИ-ассистента, а аудит находит Laravel 7, вопрос уже не просто «обновляться ли?». Полезнее спросить: «Что мы хотим построить и что для этого нужно?» Если нужна актуальная платформа, обновление перестаёт быть отдельным техническим проектом. Это первый этап продукта, который клиент на самом деле хочет.

Laravel 13, например, приносит официальный Laravel AI SDK: генерацию текста, агентов с вызовом инструментов, эмбеддинги, работу с аудио и изображениями и интеграции с векторными хранилищами. В нём же появилась встроенная поддержка векторных запросов для смыслового поиска.

Эти возможности нужны не всем. Но старая техническая основа может незаметно стать ограничением для бизнес-идеи.

БИЗНЕС-ЛОГИКА

Фреймворк это простая часть

Именно здесь ошибается большинство оценок. Клиент слышит «обновление Laravel» и представляет замену версии фреймворка. Но фреймворк обычно самая простая часть. Сложно всё, что выросло вокруг него.

Старое приложение это не просто код. Это накопленная бизнес-логика.

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

Поэтому мы не считаем старый код мусором только потому, что он старый.

Прежде чем решать, что может исчезнуть, поймите, что обязано остаться.

ДВА ОБНОВЛЕНИЯ

Обычно это два обновления

Первый сюрприз для многих владельцев: PHP и Laravel должны двигаться вместе. Laravel 13 требует минимум PHP 8.3, поэтому сайт на PHP 7.4 не может просто перепрыгнуть в конечную точку в надежде на лучшее.

Второй сюрприз: мажорные версии Laravel пропускать нельзя. Сайт на Laravel 7 проходит через 8, потом 9, потом 10 и так далее.

Одни переходы спокойные. Другие меняют базовое поведение. Laravel 9, например, заменил Swift Mailer на Symfony Mailer и перевёл работу с файлами на Flysystem 3. Как раз такие изменения превращаются в тихие поломки для бизнеса: почта перестаёт уходить, загрузки не работают, фоновое задание падает, а главная выглядит совершенно нормально.

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

АВТОМАТИЗАЦИЯ

Автоматизация, а не магия

Сервисы автоматического обновления существуют, и они действительно полезны. Самый известный это Laravel Shift: цены начинаются от $29 за один переход, а безлимитный тариф для всех репозиториев стоит $2 999 в год.

Но $29 это цена автоматического шага, а не цена уверенности, что бизнес после него работает.

Проекту, отставшему на несколько версий, нужно несколько шагов, и каждый нужно проверить. Зависимости приходится заменять, свой код переписывать, тесты запускать. А если тестов нет, поведение кто-то проверяет руками.

Сегодня уже есть демонстрации обновления Laravel за минуты с помощью Shift и ИИ. Они показывают, как далеко продвинулась автоматика. Но они не значат, что живой бизнес-сайт с годами своего кода, заброшенными пакетами и почти без тестов обновится за пятнадцать минут. По нашему опыту, даже близко нет.

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

ИИ И БИЗНЕС

Кто читает бизнес?

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

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

А самые опасные его ошибки тихие. Сайт открывается. Меню работает. Стили на месте. А тем временем форма заявок перестала доставлять письма.

Поэтому полезный вопрос не в том, может ли ИИ обновить Laravel. Значительную часть работы он автоматизирует. Полезный вопрос: кто сверит результат с реальным бизнесом. Подробнее мы разбирали это в статье «Нужен ли мне разработчик, или хватит ИИ?»

ИИ меняет экономику обновления, но не ответственность за него.

СКРЫТЫЕ ЗАТРАТЫ

Где прячутся деньги

В опросе Zend 2026 года команды назвали самой трудоёмкой частью перехода тестирование (42%), опередившее рефакторинг (36%). При этом 32% разработчиков на PHP в опросе JetBrains вообще не пишут тестов.

Это сочетание объясняет, почему старые системы бывают дорогими, даже когда кода не так уж много. Если тесты есть, система сама говорит, что что-то изменилось. Если их нет, она рассчитывает, что человек помнит, как выглядела «норма».

Дальше заброшенные пакеты. На трёхъязычном корпоративном сайте, который мы прямо сейчас обновляем с Laravel 7, за одним заброшенным пакетом для форм стоит больше двухсот полей в админке. Заменить такой пакет значит затронуть двести бизнес-процессов.

И наконец тихие поломки: почта, загрузки, задания по расписанию, индексация, интеграции. Они живут незамеченными, и именно это делает работу со старыми системами дорогой. Это тот самый скрытый технический долг, из-за которого редизайн обходится дороже.

НЕВИДИМ ДЛЯ ИИ

Сайт, которого не видит ИИ

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

Один из них мы находим снова и снова: сайт частично закрыт от ИИ-роботов, и никто этого не решал. Хостинги часто включают защиту от ботов с настройками по умолчанию, которые блокируют таких роботов, как GPTBot от OpenAI или агенты Meta. Некоторые ещё и дописывают свои правила в robots.txt, а владелец этого не замечает. Для людей сайт работает идеально. Для ChatGPT, Perplexity или ИИ-ассистента, который помогает с покупками, его почти не существует.

Мы видели это на недавнем проекте. После переезда на новый хостинг-аккаунт GPTBot и роботы Meta получали ошибку 403, а хостинг тихо добавил их в список запретов в robots.txt. На самом сайте ничего не выглядело неправильным. Чтобы это увидеть, хватило одной проверки, чтобы исправить, нескольких настроек.

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

То же с почтой. Переезд хостинга без настройки SPF и DKIM это прямой путь к тому, что заявки с сайта начинают падать в спам или исчезают, не доходя до ящика.

Поэтому каждое наше обновление заканчивается тремя проверками, которые не имеют отношения к Laravel: какие роботы могут попасть на сайт, что на самом деле написано в robots.txt после переезда и настроена ли аутентификация почты. Сделать бизнес понятным для ИИ это отдельная дисциплина, и именно ей посвящена наша AEO и GEO-оптимизация.

ИСТОРИЯ

Закопанная история

Есть ещё одна цена, которая редко попадает в смету. Память.

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

В какой-то момент кто-то открывает код и спрашивает: «Почему это работает так?» И ответить уже некому.

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

ЦЕНЫ РЫНКА

Сколько берёт рынок

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

Рынок отражает этот разброс. Платные аудиты начинаются примерно от $299, а многие компании предлагают бесплатные «аудиты», которые на деле оказываются продающим звонком с прикидкой в конце. На другом полюсе переписать старое приложение с нуля в 2026 году обычно стоит от $80 000 до более чем $3 млн, в зависимости от объёма кода и скрытой бизнес-логики.

Полезный вывод проще: стоимость обновления определяется тем, что внутри системы, а не цифрой после слова «Laravel».

РЕШЕНИЕ

Обновлять, переделывать или ждать?

Есть три честных ответа.

• Обновлять, когда сайт по-прежнему делает свою работу, бизнес-логика здравая, а главная проблема в возрасте. Модернизация сохраняет то, что уже работает, и подтягивает фундамент, а заодно открывает путь к функциям ИИ и современным интеграциям.
• Переделывать, когда стоимость безопасного обновления приближается к стоимости чистой переделки того же функционала. Распространённое правило, которым пользуемся и мы: если оценка обновления превышает примерно 60% стоимости переделки, разговор о переделке стоит провести.
• Ждать, только если сайт действительно скоро будет заменён.

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

НАШ ПРОЦЕСС

Как мы это делаем

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

Поэтому наша работа по модернизации сайтов идёт в чётком порядке:

1. Аудит. Смотрим код, пакеты, версии PHP и Laravel, хостинг, владение, интеграции и всё то, о чём легко забыть, пока оно не перестанет работать. Клиент получает письменный отчёт с планом обновления, ценой и сроками. Аудит это платный этап: $300 для небольших и средних сайтов, от $1 000 для крупного e-commerce и сложных проектов. Отчёт принадлежит клиенту, с ним можно работать с нами или с другой командой.
2. Закрытая копия. Тестовая копия закрыта от поисковиков на уровне сервера. Мы не экспериментируем на живом бизнесе.
3. По одной версии. Каждый шаг фреймворка это отдельный коммит, который проверяется до начала следующего. Если что-то пошло не так, мы откатываемся на один шаг, а не восстанавливаем весь проект.
4. Проверка клиентом. Клиент смотрит обновлённый сайт до того, как что-то изменится на рабочем.
5. Быстрая выкатка. Она может быть быстрой как раз потому, что вся сложная работа сделана заранее. Сразу после переключения проверяем то, что важно бизнесу: сайт открыт для Google, формы доставляют заявки, интеграции отвечают. Если сайт заодно переезжает на новый хостинг, идём по чек-листу переезда, который пропускает большинство агентств.
6. Наблюдение и описание. Сутки следим за сайтом после переключения, передаём письменное описание всех изменений и даём гарантию 30 дней.

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

ПЕРВЫЙ ВОПРОС

Первый вопрос

Номера версий важны. Но это не первый вопрос для бизнеса. Первый вопрос: что эта система делает для компании?

Приносит заявки? Принимает оплату? Передаёт данные в CRM? Управляет товарами? Отправляет заказы на склад? Обслуживает личный кабинет клиентов? Публикует контент, который приводит поисковый трафик? Выполняет процесс, о котором никто не помнит, потому что он давно стал рутиной?

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

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

ЗАГЛЯНУТЬ ВНУТРЬ

Главный вопрос

Если ваш сайт работает на старой версии PHP, Laravel, WordPress или OpenCart, ответ не обязательно «обновляться». И не обязательно «переделывать».

Первый шаг гораздо скромнее. Заглянуть внутрь.

Узнать, на чём вы на самом деле работаете. Узнать, что от этого зависит. Узнать, что сломается, если это изменить. Узнать, что бизнес не может позволить себе потерять.

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

Самая дорогая устаревшая система та, за которую никто не переживает.

FAQ

Вопросы и ответы

Можно ли пропускать версии Laravel при обновлении?

Нет. Laravel обновляется по одной мажорной версии за раз, например с 7 на 8, потом на 9, и PHP обычно приходится обновлять вместе с ним.

Сколько стоит обновить старый сайт на Laravel?

Зависит от того, что внутри, а не от номера версии. Обновление на одну версию в ухоженном приложении может занять день; старому приложению со своим кодом и без тестов сначала нужен аудит. Аудит небольших и средних сайтов у нас стоит $300, крупных e-commerce-проектов от $1 000.

Может ли ИИ или Laravel Shift обновить сайт автоматически?

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

Что дешевле: обновить или переделать?

Обычно обновить. О переделке стоит говорить, когда оценка обновления приближается к 60% стоимости переделки того же функционала.

Почему моего сайта нет в ответах ИИ?

Одна из частых причин техническая: хостинг или robots.txt закрывают сайт от ИИ-роботов вроде GPTBot. Это стоит проверять после любого переезда хостинга или обновления.

Какую версию PHP использовать бизнес-сайту в 2026 году?

Поддерживаемую: PHP 8.3 или новее надёжный выбор. PHP 8.2 получает исправления безопасности только до 31 декабря 2026 года.

Источники

• PHP Statistics 2026, FOSS Post (W3Techs, php.net, Zend, JetBrains, Patchstack)
• Laravel 13 release notes
• Laravel 9 release notes
• Laravel 13 Released, Laravel News
• Shift + AI: Fully Automated Laravel Upgrades, Laravel News
• Laravel Shift plans
• StackShield vs Laravel Shift
• Upgrading with Laravel Shift, CodeWithSusan
• How Much a Laravel Version Upgrade Costs, Dev Loader
• Laravel Version Upgrade Cost in 2026, Acquaint Softtech
• Laravel Version Upgrades: Why Falling Behind Costs More Every Year, Rocking Tech
• Cost to Rewrite a Legacy Application in 2026, Cadence