Авторы: команда Brightcode, небольшое агентство веб-разработки из Дели (NCR). Рецензент: Гаурав Кхоккар, основатель.

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

Вскоре это станет серьезной проблемой для многих команд. Согласно официальному календарю поддержки PHP,  последние исправления безопасности для PHP 8.2 выйдут 31 декабря 2026 года. Версии от 8.1 и ниже уже вышли из-под поддержки. Данные W3Techs по состоянию на 29 октября 2026 года показывают, что  26,5% PHP-сайтов все еще работают на PHP 7, а  7,7% — на PHP 5.

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

1. Запишите, что именно сейчас запущено

Прежде чем что-либо менять, зафиксируйте:

  • Версию PHP на сервере ( php -v  через SSH или в панели хостинга).
  • Фреймворк и его версию, если он используется. Для Laravel:  php artisan --version .
  • Все PHP-расширения, которые задействует приложение ( php -m ), так как в новой сборке PHP на сервере некоторых из них может не оказаться.
  • Крон-задачи (cron jobs), воркеры очередей и все остальное, что выполняется вне веб-запросов. Именно об этих частях чаще всего забывают при тестировании.

Оформите это в виде небольшого файла  UPGRADE.md  в репозитории. Если репозитория еще нет, это нулевой шаг: поместите код в Git ровно в том виде, в каком он находится на сервере.

2. Сделайте бэкап, который вы действительно восстанавливали

Резервная копия, которую вы не пробовали восстанавливать, — это просто предположение, что она работает. Сделайте дамп базы данных, скопируйте файлы и восстановите и то, и другое на стейджинг-сервер или в локальное окружение Docker. Если приложение там запустилось, у вас есть безопасное место для экспериментов.

3. Спросите у Composer, что мешает обновлению

Composer может подсказать, какие пакеты несовместимы с нужной вам версией PHP. На стейджинг-копии выполните:

 # which installed packages would stop you running PHP 8.3?
composer why-not php 8.3

# does this machine meet the lock file's requirements?
composer check-platform-reqs

# which direct dependencies have newer versions?
composer outdated --direct
 

Чтобы разрешить зависимости так, будто на сервере уже установлена целевая версия, вы можете временно указать платформенную версию PHP в  composer.json  на время работы:

 {
  "config": {
    "platform": {
      "php": "8.3"
    }
  }
}
 

Не забудьте обновить это значение при переходе к следующей версии или удалить его, если ваш деплой опирается на реальную версию PHP на сервере.

4. Поручите Rector рутинные изменения кода

Rector переписывает код под новые версии PHP: удаленные функции, измененные сигнатуры, новый синтаксис. Начните с сухого прогона (dry run), чтобы сначала ознакомиться со всеми изменениями.

 <?php
// rector.php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/app', __DIR__ . '/src'])
    ->withPhpSets(php83: true);
 
 vendor/bin/rector process --dry-run
 

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

5. Двигайтесь по одному шагу за раз

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

 composer require laravel/framework:^12.0 --with-all-dependencies
 

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

6. Протестируйте сценарии, которые приносят деньги

Запустите набор тестов, если он есть. Если нет — напишите несколько тестов для самых важных путей до начала работ, а не после: авторизация, основная форма или оформление заказа, платежные вебхуки (callbacks), отправка писем и хотя бы одна фоновая задача. Даже небольшое количество функциональных тестов поймает большую часть багов, возникающих при обновлении.

Затем проверьте вручную на стейджинге:

  • Формы отправляются, а уведомления по электронной почте или в WhatsApp доходят.
  • Тестовый режим платежного шлюза работает от начала и до конца, включая callback.
  • Загрузка файлов, генерация PDF или инвойсов, а также обработка изображений (все это зависит от расширений).
  • Крон-задачи и воркеры очередей действительно запускаются на новой версии PHP. Также проверьте версию для CLI, поскольку веб-сервер и командная строка могут использовать разные бинарные файлы PHP.

7. Переключите продакшн и следите за ним

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

Если обновление также затрагивает URL-адреса (например, вы переводите приложение на новый фреймворк или домен), это миграция, а не просто обновление. Сначала спланируйте редиректы. Наш чек-лист по миграции сайтов охватывает SEO-аспекты этой задачи.

Когда вместо обновления пора сделать переписывание с нуля

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

Источники

Brightcode — команда веб-разработки из Дели (NCR). Мы обновляем и переносим старые сайты на PHP и WordPress в рамках услуги миграции платформ, а также поддерживаем их актуальное состояние с помощью управляемого хостинга и технического обслуживания.