Миграция на PHP 8: пошаговый план без простоев
Два одинаковых открытых ящика с одинаковыми деталями, из одного выпадает одна изумрудная деталь
Интеграции и Разработка ПО22 октября 2026 г. 12 минут чтения 2 просмотра

Миграция на PHP 8: пошаговый план без простоев

Миграция на PHP 8: аудит кода, обновление зависимостей, статанализ, тесты на staging и безопасное переключение продакшена с планом отката.

Миграция на PHP 8: что нужно знать и как её провести

Миграция на PHP 8 — это поэтапный процесс: аудит кода и зависимостей, обновление библиотек, статический анализ, тесты на staging и контролируемое переключение продакшена с планом отката. Для большинства проектов она занимает от нескольких дней до нескольких недель.

Главный риск — не сам PHP 8, а устаревшие библиотеки и «тихие» ошибки, которые раньше прощал интерпретатор.

Ветка PHP 7.4 больше не получает исправлений безопасности, а значит, сайт или сервис на ней остаётся уязвимым и постепенно теряет совместимость с новыми версиями фреймворков, CMS и пакетов Composer. В этой статье разберём, зачем переходить, что именно ломается, как построить процесс миграции и что проверить в Яндекс Вебмастере и Google Search Console после переключения.

Почему откладывать миграцию рискованно

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

Вторая причина — экосистема. Современные версии Laravel, Symfony, WordPress и популярных плагинов требуют PHP 8.x. Чем дольше вы остаётесь на старой версии, тем больше накапливается технический долг: обновить одну библиотеку без другой уже не получается, и в итоге переход превращается в большой и дорогой проект вместо плановой работы.

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

что нового

Возможности PHP 8, которые меняют код

01 · php 8.0

JIT-компилятор

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

02 · php 8.0

Union types и mixed

Тип параметра можно описать как int|string или mixed. Сигнатуры становятся точнее, а ошибок типов — меньше.

03 · php 8.0

Именованные аргументы

Вызов вида setcookie(name: 'a', httponly: true) избавляет от длинных цепочек значений по умолчанию.

04 · php 8.0

match и nullsafe

Строгая замена громоздкому switch и оператор ?-> вместо вложенных проверок на null.

05 · php 8.0

Constructor promotion

Свойства объявляются прямо в конструкторе. Вместе с атрибутами это заметно сокращает шаблонный код.

06 · php 8.1

Enum и readonly

Нативные перечисления и неизменяемые свойства заменяют константы-«костыли» и самодельные value-объекты.

С чего начать: аудит проекта

Миграция начинается не с переключения версии в панели хостинга, а с инвентаризации. Нужно понять, на какой версии PHP проект работает сейчас, какие расширения использует (mbstring, intl, curl, gd, imagick и другие), какие пакеты подключены через Composer и насколько давно они обновлялись. Отдельно выпишите всё, что не управляется через Composer: плагины CMS, самописные модули, скрипты в cron, интеграции с платёжными системами и CRM.

Полезная команда на этом этапе — `composer why-not php 8.3`: она покажет, какие пакеты блокируют переход на нужную версию. Команда `composer check-platform-reqs` проверит, что расширения и версия PHP на сервере соответствуют требованиям зависимостей. Если проект работает на CMS вроде WordPress или 1С-Битрикс, сверьте требования вашей редакции и всех установленных модулей к версии PHP: именно сторонние плагины чаще всего оказываются слабым звеном.

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

Пошаговый план миграции на PHP 8

  1. 01

    Инвентаризация: зафиксируйте текущую версию PHP, список расширений, composer.json и composer.lock, версию CMS или фреймворка, список плагинов и cron-задач.

  2. 02

    Обновление зависимостей: найдите пакеты, не поддерживающие PHP 8, обновите их или подберите замену. Устаревшие и заброшенные библиотеки лучше убрать сразу.

  3. 03

    Статический анализ и автоматический рефакторинг: запустите PHPStan или Psalm, проверку PHPCompatibility через PHP_CodeSniffer и набор правил Rector для нужной версии.

  4. 04

    Тестовое окружение: поднимите staging с PHP 8 (например, в Docker-образе php-fpm нужной версии) с теми же расширениями, конфигурацией и версией СУБД, что и на продакшене.

  5. 05

    Тестирование: включите error_reporting = E_ALL, прогоните автотесты и критичные сценарии вручную, изучите логи на предмет Warning, Deprecated и TypeError.

  6. 06

    Нагрузочная проверка: сравните время ответа и потребление памяти до и после миграции на реалистичной нагрузке, настройте OPcache и при необходимости оцените JIT.

  7. 07

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

  8. 08

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

Инструменты, которые экономят недели

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

Rector умеет автоматически переписывать код: заменять устаревшие конструкции, добавлять типы, применять constructor promotion. Подключайте его наборами правил для конкретной версии и обязательно просматривайте дифф перед коммитом — автоматическая правка без ревью допустима только при хорошем покрытии тестами.

PHP_CodeSniffer с набором PHPCompatibility проверяет, не используются ли в коде функции и синтаксис, несовместимые с целевой версией. А для понимания реальной картины на staging пригодятся логи PHP и сервис сбора ошибок вроде Sentry: он группирует исключения и показывает, какие сценарии действительно падают.

Что изменилось в PHP 8Чем это грозитЧто делать
Сравнение строки с числом: 0 == "abc" теперь falseМеняется логика условий и фильтров, особенно в старом коде с нестрогими сравнениямиИспользовать === и покрыть тестами ключевые условия
Недопустимые операции (арифметика с массивом, неверный тип аргумента встроенной функции) бросают TypeErrorТам, где раньше был Notice, теперь исключение и ошибка 500Включить E_ALL на staging, приводить типы явно
Удалены create_function(), each(), доступ к символу через $str{0}Фатальная ошибка при запуске старых библиотек и плагиновЗаменить на замыкания и foreach, писать $str[0], обновить зависимости
Оператор @ больше не скрывает фатальные ошибкиСкрытые ранее ошибки всплывают в логах, а на проде приводят к сбоямОбрабатывать ошибки явно и регулярно проверять логи
Необязательный параметр перед обязательным помечен как устаревшийDeprecated в логах сегодня, потенциальная ошибка в будущих версияхПереупорядочить параметры в сигнатурах функций и методов

Как читать таблицу несовместимостей

Таблица выше — не полный перечень, а наиболее частые источники проблем. Полный список вы найдёте в официальных руководствах по миграции на каждую минорную версию в документации PHP: обязательно прочитайте разделы Backward Incompatible Changes и Deprecated Features для всех версий между вашей текущей и целевой.

Обратите внимание на разницу между исключениями и предупреждениями. Многие проблемы PHP 8 проявляются не как падение при запуске, а как поведение, которое раньше «просто работало». Например, обращение к неопределённому ключу массива теперь даёт Warning, а передача `null` во встроенные функции, ожидающие строку, в версии 8.1 считается устаревшей. В продакшене с отключённым выводом ошибок такие сообщения оседают в логах и могут месяцами оставаться незамеченными, пока не станут реальным сбоем при обновлении до следующей версии.

Отдельная тема — расширения и ресурсы. В PHP 8 ряд ресурсов превратился в объекты (например, дескрипторы curl и изображения GD), поэтому код, который проверял их через `is_resource()`, нужно переписать.

Типичные ошибки при переходе на PHP 8

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

Как делать не стоит

  • Переключать версию PHP сразу на продакшене без staging
  • Подавлять ошибки через @ и отключать вывод вместо исправления причин
  • Обновлять PHP и одновременно переписывать большие части приложения
  • Игнорировать расширения: на новом сервере нет нужного модуля или он собран иначе
  • Не делать резервную копию и не готовить откат

Как правильно

  1. 01

    Воспроизвести продакшен на staging: те же расширения, версия СУБД, конфигурация

  2. 02

    Исправлять причины Warning и Deprecated, а не прятать их

  3. 03

    Разделять задачи: сначала миграция, затем рефакторинг и новые функции

  4. 04

    Сверить phpinfo() старого и нового окружения до переключения

  5. 05

    Подготовить бэкап файлов и базы и проверить, что откат занимает минуты

было / стало

Тот же код: PHP 7.x и PHP 8

было · php 7.x
class User {
    private $name;
    private $email;

    public function __construct($name, $email) {
        $this->name = $name;
        $this->email = $email;
    }
}

$city = null;
if ($user && $user->getAddress()) {
    $city = $user->getAddress()->getCity();
}

14 строк, типы не заданы, проверки на null вручную.

стало · php 8.x
class User {
    public function __construct(
        private string $name,
        private string $email,
    ) {}
}

$city = $user?->getAddress()?->getCity();

7 строк, строгие типы, nullsafe-оператор вместо цепочки условий.

Что проверить после миграции: SEO и мониторинг

Версия PHP не входит в факторы ранжирования, но ошибки сервера и замедление ответа напрямую сказываются на индексации и пользовательском опыте. В первые дни после переключения регулярно открывайте Яндекс Вебмастер (раздел с диагностикой сайта и статистикой обхода) и Google Search Console (отчёты об индексации и статистика сканирования): всплеск ошибок 5xx или падение числа обработанных страниц — сигнал, что что-то пошло не так.

Параллельно сравните поведенческие показатели в Яндекс Метрике и Google Analytics: рост отказов на отдельных страницах, падение конверсии формы или оформления заказа часто выдают скрытую ошибку, которую не заметили на тестах. Если вы используете рекламу в Яндекс Директе или Google Ads, убедитесь, что счётчики целей и серверная отправка событий продолжают работать.

Отдельно проверьте скорость ответа сервера (TTFB) и потребление памяти. Если после миграции время ответа выросло, вероятнее всего, не настроен OPcache или не подгрузились расширения.

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

Что даёт переход на PHP 8

  1. 01

    Закрытые уязвимости: сервер снова получает обновления безопасности

  2. 02

    Совместимость с актуальными версиями фреймворков, CMS и пакетов Composer

  3. 03

    Улучшенная производительность и более эффективная работа с памятью

  4. 04

    Строгая типизация и современный синтаксис: меньше ошибок и проще сопровождение

  5. 05

    Более понятные сообщения об ошибках и надёжная отладка

  6. 06

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

План отката и работа с хостингом

Даже при идеальной подготовке нужен план отката. Если вы работаете на VPS или собственном сервере, держите две версии PHP-FPM параллельно и переключайте их на уровне конфигурации веб-сервера (Nginx или Apache): откат занимает минуты. На обычном виртуальном хостинге версию PHP обычно можно сменить в панели управления для каждого сайта отдельно — используйте это, чтобы сначала перевести тестовый поддомен.

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

Заранее договоритесь, кто и по каким критериям принимает решение об откате: например, при росте числа ошибок 5xx выше заданного порога в течение 15 минут. Чёткое правило избавляет от споров в момент, когда время дорого.

go / no-go

Чек-лист перед переключением продакшена

01

Composer-зависимости совместимы с целевой версией PHP

02

Автотесты и ручные сценарии пройдены на staging без ошибок

03

В логах нет новых Warning, Deprecated и TypeError

04

Расширения PHP и настройки OPcache сверены с продакшеном

05

Свежие бэкапы файлов и базы данных проверены на восстановление

06

Назначены ответственный за откат и критерии его запуска

Итоги: как мигрировать на PHP 8 спокойно

Успешная миграция на PHP 8 — это подготовка, а не героизм в день переключения.
  1. 01

    Проведите аудит: версия PHP, расширения, зависимости, плагины, cron-задачи

  2. 02

    Обновите библиотеки и уберите заброшенные пакеты до начала миграции

  3. 03

    Используйте PHPStan или Psalm, Rector и PHPCompatibility для поиска проблем

  4. 04

    Тестируйте на staging с конфигурацией, идентичной продакшену

  5. 05

    Переключайте продакшен с готовым планом отката и мониторингом

  6. 06

    После запуска следите за Яндекс Вебмастером, Google Search Console и логами сервера

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

Часто задаваемые вопросы

Проверим ваш код и подготовим безопасный переход на PHP 8

Проведём аудит совместимости, составим план миграции и назовём сроки до начала работ

Аудит совместимостиТестовое окружениеПлан отката

Миграции проектов без простоев

Читайте также

Две стопки пустых карточек разной высоты на изометрической подложке, на верхней карточке низкой стопки зелёная заливка
Обновление PHP на сайте: услуга, этапы и рискиОбновление PHP — услуга по переводу сайта на поддерживаемую версию языка: аудит, тесты, миграция и откат. Рассказываем, как это работает.
Три ряда одинаковых пустых карточек на подложке, в свободной ячейке лежит маленький зелёный шарик
Аудит PHP-кода: чек-лист, этапы и инструментыАудит PHP-кода — это проверка проекта на уязвимости, ошибки, медленные места и технический долг. Разбираем этапы, инструменты и типичные ошибки.

Политика конфиденциальности

При оставлении заявки на ресурсе «https://gurucontext.ru» пользователи предоставляют следующие сведения:

  • Имя
  • Контактный телефон или Telegram
  • Адрес сайта пользователя (не обязательно)

Также администрация сайта получает данные об IP-адресе посетителей, типе браузера, времени нахождения на сайте и прочие подобные сведения через сервисы статистики.

Использование информации

Вся полученная информация используется администрацией «https://gurucontext.ru» исключительно в целях связи с клиентом.

Защита персональных данных

Компания «https://gurucontext.ru» обязуется не разглашать сведения, полученные от пользователей, и хранит их в защищённом виде.

Предоставление данных третьим лицам

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

Контакты

Телефон: +7 (499) 955-47-00.
E-mail: info@gurucontext.ru.