Миграция сайта на 1С-Битрикс на PHP 8: совместимость, тестирование, ускорение

Сайт годами работал на PHP 7.4, а теперь хостинг предупреждает о снятии поддержки, антивирус модуля проактивной защиты подсвечивает устаревшее окружение, а новые версии ядра и модулей Маркетплейса всё чаще требуют PHP 8. Переход назрел, но пугает: «а вдруг после переключения версии половина каталога отвалится, перестанет ходить обмен с 1С, а оформление заказа выдаст белый экран». Страх обоснованный — но управляемый. Миграция на PHP 8 — это не «нажать кнопку на хостинге», а последовательность проверок, при которой сюрпризов почти не остаётся.

Ниже — практический разбор миграции сайта на 1С-Битрикс на PHP 8: какие версии поддерживает актуальное ядро, где реально спрятан выигрыш в скорости, как пользоваться встроенной «Проверкой совместимости», какие изменения языка чаще всего ломают код и в каком порядке безопасно доводить всё до прода с возможностью отката. Это выжимка из наших проектов по поддержке и сопровождению сайтов на 1С-Битрикс — без теории ради теории, только то, что реально влияет на исход миграции.

Зачем переходить на PHP 8

У миграции на PHP 8 три движущих мотива, и все они практические, а не «чтобы было по-модному».

Безопасность и поддержка. Старые ветки PHP рано или поздно перестают получать обновления безопасности. Для сайта, который принимает оплату и хранит персональные данные клиентов, работа на версии без патчей — это не абстрактный, а вполне конкретный риск. Хостинги и без того всё активнее выводят из эксплуатации 7.x, и рано или поздно вопрос встанет ребром — лучше решить его планово, чем в аварийном режиме, когда провайдер отключит старую версию по расписанию.

Совместимость с новыми версиями ядра и модулей. 1С-Битрикс развивается, и свежие обновления главного модуля, а также многие продукты Маркетплейса, всё чаще проектируются под PHP 8. Оставаясь на 7.4, вы постепенно упираетесь в потолок: часть обновлений уже не встанет, часть решений из Маркетплейса не установится. Миграция на PHP 8 снимает этот потолок и открывает путь к актуальным версиям.

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

Какие версии PHP поддерживает Битрикс

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

Актуальные редакции «1С-Битрикс: Управление сайтом» рассчитаны на работу под PHP 8.1 и 8.2. Ветка 7.4 ещё поддерживается многими проектами, но считается уходящей: новых улучшений под неё нет, а обновления безопасности самого PHP для неё уже прекращены. Ветки старше 7.4 (7.1–7.3, а тем более 5.x) для актуального ядра неприемлемы. Практический смысл такой:

• PHP 7.4 — то, с чего вы, скорее всего, уходите. Работает, но без будущего: рано или поздно хостинг снимет её с поддержки.
• PHP 8.1 — самый обкатанный целевой вариант. Максимум совместимости с модулями Маркетплейса и минимум сюрпризов. Хороший выбор «по умолчанию» для большинства магазинов.
• PHP 8.2 — быстрее и свежее, но требует более актуального ядра и обновлённых модулей. Стоит выбирать, когда проект уже в хорошем состоянии и вы готовы дочинить чуть больше мелочей.
• PHP 8.3 и новее — рассматривайте осторожно и только после проверки, что ваша версия ядра официально с ней работает; иначе легко наткнуться на несовместимости в самом ядре, а не только в кастоме.

Отдельно стоит учесть редакцию и её модули. Магазину на «Малом бизнесе» или «Бизнесе» важно, чтобы не только главный модуль, но и модули торгового каталога, интернет-магазина, обмена с 1С были обновлены до версий, где заявлена поддержка выбранной ветки PHP. Именно поэтому перед сменой версии PHP почти всегда идёт этап обновления ядра и модулей — рассинхрон «свежий PHP, старое ядро» ведёт к ошибкам в самой платформе.

Выигрыш производительности: opcache и JIT

Вокруг скорости PHP 8 много мифов, поэтому разложим по полочкам, откуда на самом деле берётся ускорение и где его ждать не стоит.

Движок и opcache — основной источник выигрыша. В PHP 8 переработан внутренний движок (в частности, за счёт компиляции байткода в более эффективную форму), а связка с opcache даёт кумулятивный эффект. Opcache — это кэш скомпилированного байткода: он избавляет PHP от повторного разбора и компиляции одних и тех же файлов на каждом запросе. Для Битрикса, где на страницу подключаются сотни файлов ядра и компонентов, это критично. Правильно настроенный opcache сам по себе даёт больший прирост, чем любые «магические» директивы.

JIT — не серебряная пуля для веб-кода. JIT (Just-In-Time компиляция) переводит горячий байткод в машинный код прямо во время выполнения. Это отлично работает для «числодробилок» — тяжёлых математических циклов, обработки изображений, шифрования. Но типичная страница магазина на Битриксе почти всё время проводит не в вычислениях, а в ожидании ответа от базы данных и в операциях ввода-вывода. На такой нагрузке JIT добавляет считаные проценты, а иногда наоборот вносит нестабильность и лишний расход памяти. Поэтому базовая рекомендация: opcache — включаем и настраиваем всегда, JIT — рассматриваем точечно и только с замерами.

Насколько именно ускорится ваш сайт — вопрос замеров, а не веры. На одном проекте прирост будет 15%, на другом — 30%, потому что всё зависит от доли времени, которое код проводит в PHP против базы. Поэтому в план миграции обязательно закладывают контрольные замеры «до» и «после»: время генерации ключевых страниц, число и длительность SQL-запросов, потребление памяти. Без цифр «стало быстрее» — это ощущение, а не результат, которым можно управлять. Тему производительности базы, которая часто оказывается настоящим узким местом, мы разбираем в отдельном материале про оптимизацию базы MySQL в Битриксе.

Проверка совместимости в самом Битриксе

Хорошая новость: значительную часть работы по проверке готовности к PHP 8 Битрикс делает за вас — надо только знать, где смотреть. В платформе есть несколько встроенных инструментов, и грамотная миграция начинается именно с них, а не с переключения версии на хостинге.

Модуль «Проверка системы» (Проверка сервера). Находится в административной части и показывает окружение глазами Битрикса: версию PHP, установленные и недостающие расширения, лимиты памяти и времени выполнения, права на файлы, параметры базы. Это первое, что нужно открыть: инструмент сразу скажет, каких PHP-модулей не хватает для нормальной работы и не упирается ли что-то в устаревшие настройки.

«Проверка совместимости с PHP». Отдельный инструмент, который сканирует ядро и (в ряде конфигураций) код проекта на использование устаревших и удалённых конструкций языка. Он формирует отчёт с перечнем потенциально проблемных мест: где встречаются снятые функции, устаревшие вызовы, конструкции, которые в новых версиях PHP работают иначе. Этот отчёт — карта того, что предстоит проверить и починить.

Отчёты и логи. В процессе миграции незаменимо журналирование ошибок. Битрикс умеет собирать исключения и ошибки в журнал событий, а на уровне PHP включается запись в лог-файл. На тестовом контуре имеет смысл выкрутить уровень логирования пожёстче, чтобы ловить не только фатальные ошибки, но и deprecated-предупреждения — именно они предупреждают о том, что «пока работает, но скоро сломается».

1. Откройте «Проверку системы». Зафиксируйте текущую версию PHP, недостающие расширения и упирающиеся лимиты. Это стартовая точка миграции.
2. Запустите «Проверку совместимости с PHP». Получите отчёт по устаревшим конструкциям в ядре и коде. Выгрузите или сохраните его — это ваш план правок.
3. Проверьте статус обновлений. Убедитесь, что главный модуль и ключевые модули (каталог, интернет-магазин, обмен с 1С) обновлены до версий с поддержкой целевой ветки PHP.
4. Включите подробное логирование на тесте. Настройте запись ошибок и deprecated-уведомлений в лог, чтобы ловить проблемы при прогоне сценариев.

Ломающие изменения PHP 8, о которых надо знать

Чтобы понимать отчёты о совместимости и осмысленно чинить код, полезно держать в голове набор изменений, которые в PHP 8 чаще всего ломают старые проекты. Разберём главные.

Удалённые функции. В PHP 8 окончательно исчезли конструкции, которые давно были помечены устаревшими. Самые болезненные для старого кода Битрикса:

• create_function() — динамическое создание функций из строки. Удалена полностью; заменяется анонимными функциями (замыканиями).
• each() — обход массива по одному элементу. Удалена; заменяется циклом foreach.
• Ряд функций и алиасов, помеченных deprecated в 7.x, — например, устаревшие способы работы с некоторыми расширениями.

Фигурные скобки для доступа к строкам и массивам. Синтаксис вида $str{0} для получения символа строки удалён — нужно использовать квадратные скобки $str[0]. Это одна из самых частых мелких правок в старых шаблонах и компонентах.

Более строгая типизация и ошибки вместо предупреждений. PHP 8 стал строже: многие ситуации, которые раньше давали «тихий» warning или notice и код всё равно как-то работал, теперь превращаются в ошибки уровня TypeError или Error. Типичные случаи — передача аргумента неверного типа во внутреннюю функцию, обращение к методу на null, несоответствие объявленным типам. Код, который «жил» на предупреждениях, в PHP 8 падает по-настоящему.

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

Изменения в сравнении строк и чисел. PHP 8 изменил правила нестрогого сравнения между строкой и числом. Раньше выражение вроде 0 == "abc" давало true (строка приводилась к числу 0), теперь — false (число приводится к строке). Это тонкое изменение способно поменять поведение старых условий и проверок, особенно в самописной валидации и фильтрах.

Изменения в поведении функций. Ряд встроенных функций стал строже относиться к аргументам и возвращаемым значениям; некоторые перестали «прощать» неверный тип и вместо false бросают исключение. Всё это выявляется прогоном сценариев с логами, а не чтением документации наизусть.

Кастомный код, модули Маркетплейса и шаблоны

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

Кастомный код. Это правки в init.php, обработчики событий, самописные компоненты и классы, вспомогательные скрипты, интеграции. Именно здесь чаще всего живут create_function(), обращения к неинициализированным переменным, неявные приведения типов. Такой код никто, кроме вас, не проверял на совместимость — его придётся прогонять и чинить вручную.

Старые модули Маркетплейса. Решения из Маркетплейса бывают разного возраста и качества. Свежие и поддерживаемые авторы обновляют под PHP 8, но заброшенные или очень старые модули могут содержать удалённые конструкции. По каждому стороннему модулю нужно проверить: есть ли обновление с поддержкой PHP 8, поддерживается ли он вообще, и что делать, если автор пропал. Иногда выгоднее заменить брошенный модуль на аналог, чем чинить чужой необновляемый код.

Шаблоны сайта и компонентов. Кастомные шаблоны дизайна и переопределённые шаблоны компонентов (в папках local или bitrix/templates) — это тоже PHP-код, часто написанный давно. Здесь встречаются и фигурные скобки для строк, и устаревшие вызовы, и логика, завязанная на старое поведение сравнений. Шаблоны нужно прогонять на реальных страницах: каталог, карточка товара, корзина, оформление заказа, личный кабинет.

Отдельно стоит сказать про качество самой проверки. Автоматический отчёт совместимости хорошо ловит явные вещи (удалённые функции), но плохо видит логические изменения — например, что старое условие с нестрогим сравнением теперь ведёт себя иначе. Такие вещи ловятся только прогоном бизнес-сценариев и тестами. Как выстроить тестирование магазина системно, мы разбираем в материале про тестирование и QA магазина на Битриксе.

Порядок миграции: от теста до прода

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

1. Тестовый контур. Разворачиваем копию сайта в окружении с целевой версией PHP 8. Прод при этом продолжает жить на 7.4 и ничего не замечает.
2. Фикс кода. Прогоняем сценарии на тесте, собираем ошибки из логов и отчёта совместимости, чиним кастом, модули и шаблоны до «зелёного» состояния.
3. Нагрузочное тестирование. Убеждаемся, что под нагрузкой сайт не только не падает, но и работает быстрее; замеряем метрики и сравниваем с 7.4.
4. Прод. Переключаем версию PHP на боевом сайте в окно низкой нагрузки, с готовым откатом и снятой резервной копией, затем прогоняем регресс.

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

Тестовый контур: как собрать и не навредить

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

1. Снимите полную копию. Файлы проекта и дамп базы данных с прода. Важно копировать целиком: и bitrix, и local, и upload, чтобы кастом и загруженные данные были на месте.
2. Разверните на отдельном окружении. Поднимите копию на PHP 8 целевой версии — на отдельном домене, поддомене или в изолированном контейнере. Никаких общих с продом баз и файлов.
3. Отключите «боевые» интеграции. На тесте нельзя допустить реальных списаний оплаты, отправки писем клиентам, боевого обмена с 1С в продуктивную базу. Переведите платёжки в тестовый режим, почту — на заглушку, обмен — на тестовую базу 1С.
4. Синхронизируйте версии ядра и модулей. Тест должен идти на том же ядре, что планируется на проде. Проверять PHP 8 на устаревшем ядре бессмысленно.
5. Включите подробное логирование. На тесте не жалко строгих настроек: пусть PHP пишет в лог все ошибки и предупреждения, включая deprecated. Здесь они — помощники, а не помеха.

Фикс кода: как искать и чинить ошибки

Когда тестовый контур поднят, начинается основная работа — прогон сценариев и починка. Методика простая и предсказуемая.

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

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

Идите по логам. После каждого прогона открывайте лог ошибок PHP и журнал событий Битрикса. Fatal-ошибки чините в первую очередь — они рушат страницы. Deprecated-предупреждения — во вторую: они пока не ломают, но это долги, которые лучше закрыть сразу, пока контекст свеж.

Чините в правильном месте. Кастомный код правьте у себя. Ошибку в стороннем модуле — по возможности решайте обновлением модуля или обращением к автору, а не «горячей» правкой чужих файлов, которую снесёт следующее обновление. Никогда не правьте файлы ядра напрямую — используйте события и переопределения.

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

Настройка php.ini и opcache

Смена версии PHP — повод пересмотреть настройки. Значения по умолчанию редко оптимальны для магазина на Битриксе. Ключевые параметры делятся на две группы: базовые лимиты и настройки opcache.

Базовые лимиты php.ini. Битрикс требователен к ресурсам, и рекомендованные им значения нужно выставить осознанно:

Opcache — где прячется скорость. Именно настройки opcache дают большую часть выигрыша PHP 8, поэтому им стоит уделить отдельное внимание:

• Достаточно памяти под кэш. Параметр памяти opcache должен вмещать весь скомпилированный код проекта. Битрикс большой, файлов много — экономия здесь оборачивается постоянными пересборками и просадкой.
• Поднятый лимит числа файлов. В проекте на Битриксе тысячи PHP-файлов. Лимит кэшируемых файлов нужно поднять с запасом, иначе часть кода не попадёт в кэш и будет компилироваться на каждом запросе.
• Проверка изменений файлов. На проде частоту проверки актуальности файлов снижают (код меняется редко), что экономит ресурсы. На тесте и при активной разработке проверку оставляют чаще, чтобы правки применялись сразу.
• Preloading — осторожно. Предзагрузка классов ускоряет старт, но требует аккуратной настройки и совместимости; включайте её осознанно и с проверкой, а не «на всякий случай».

Нагрузочное тестирование перед продом

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

Что важно проверить под нагрузкой:

• Стабильность. Сайт не должен падать, ронять процессы или упираться в лимиты памяти при потоке параллельных запросов, сопоставимом с пиковым боевым.
• Сравнение скорости с 7.4. Прогоните один и тот же профиль нагрузки на 7.4 и на 8.x. Именно здесь вы получите честную цифру прироста для своего проекта, а не из чужих статей.
• Поведение opcache. Убедитесь, что кэш не переполняется и не «выселяет» код: если файлов больше лимита или памяти мало, часть кода будет постоянно перекомпилироваться, и весь выигрыш PHP 8 растворится.
• Тяжёлые операции. Проверьте под нагрузкой не только витрину, но и обмен с 1С, массовый импорт, генерацию больших выгрузок — то, что сильнее всего грузит ресурсы.

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

Переключение прода и откат

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

1. Выберите окно низкой нагрузки. Ночь или раннее утро, когда покупателей минимум, а обмен с 1С не идёт. Предупредите заинтересованных: маркетинг, менеджеров, того, кто ведёт обмен.
2. Снимите свежую резервную копию. Файлы и база непосредственно перед переключением. Это ваша страховка, к которой можно вернуться в любой момент.
3. Меняйте только версию PHP. Не совмещайте переключение PHP с обновлением ядра, правкой структуры базы или выкладкой новой функциональности. Одно изменение за раз — одна возможная причина, если что-то пойдёт не так.
4. Переключите версию. Через панель хостинга или конфиг веб-сервера смените версию PHP на целевую. Заранее убедитесь, что откат на 7.4 выполняется одной операцией.
5. Сразу прогоните регресс. Пройдите ключевые сценарии на живом сайте и загляните в логи. Тихих ошибок быть не должно.

Про откат. Безопасный откат — это не «план Б на случай катастрофы», а штатная часть процедуры, которую готовят заранее. Условие простое: вернуть версию PHP на предыдущую должно быть возможно быстро и без потерь. Именно поэтому на этапе переключения не меняют ничего, кроме версии PHP: если бы вы одновременно обновили ядро или изменили базу, откат PHP уже не вернул бы систему в прежнее состояние. Если после переключения всплывают критичные ошибки — возвращаете 7.4, сайт продолжает работать, а проблемы дочиняете на тесте и выходите на прод повторно.

Регрессионное тестирование каталога, заказов и 1С

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

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

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

Обмен с 1С. Запустите обмен на тесте и проверьте оба направления: выгрузку каталога из 1С на сайт (товары, цены, остатки, свойства) и передачу заказов с сайта в 1С. Убедитесь, что данные не теряются и не искажаются, что кодировки и типы обрабатываются верно. Обмен часто чувствителен к строгой типизации PHP 8 и изменениям в обработке строк.

Чтобы понимать, как выглядит контроль версии PHP глазами платформы, полезно представлять экран «Проверки системы» — именно с него удобно начинать и им же подтверждать результат после переключения:

Реализация в 1С-Битрикс: что нажимать

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

1. Настройки → Инструменты → «Проверка системы». Смотрим текущую версию PHP, расширения и лимиты. Фиксируем стартовое состояние.
2. «Проверка совместимости с PHP». Запускаем сканирование, получаем отчёт об устаревших конструкциях в ядре и коде. Отчёт становится планом правок.
3. Marketplace → «Обновление платформы». Приводим главный модуль и модули (каталог, интернет-магазин, обмен с 1С) к версиям с поддержкой целевого PHP. Делаем это до смены версии PHP.
4. Панель хостинга / конфиг веб-сервера. На тестовом контуре переключаем версию PHP на 8.x. На проде — только после успешного теста и нагрузки.
5. php.ini / настройки PHP. Выставляем memory_limit, лимиты загрузок, включаем и настраиваем opcache (память, число файлов, проверка изменений).
6. Журнал событий и лог ошибок PHP. После прогонов сценариев проверяем логи, чиним fatal-ошибки, затем deprecated. Повторяем до чистого лога.
7. Обмен с 1С. На тесте гоняем обмен в обе стороны в тестовую базу, проверяем целостность данных. На прод выходим с уверенностью, что обмен переживёт смену версии.

Частые ошибки

• Переключают версию PHP сразу на проде «чтобы проверить» — и ловят белый экран на живых покупателях вместо спокойной отладки на тесте.
• Меняют версию PHP и обновляют ядро одним заходом — когда что-то ломается, невозможно понять, что виновато, и откат не возвращает систему в прежнее состояние.
• Проверяют PHP 8 на устаревшем ядре — ловят ошибки самой платформы, которые не имеют отношения к их коду, и тратят время впустую.
• Полагаются только на автоматическую «Проверку совместимости» — она не видит логических изменений (например, новых правил сравнения строк и чисел) и не заменяет прогон сценариев.
• Забывают про фоновые процессы — агенты, крон, обмен с 1С, импорт ломаются молча, потому что их не гоняли при регрессе.
• Не настраивают opcache под размер проекта — памяти и лимита файлов не хватает, код постоянно перекомпилируется, и весь выигрыш PHP 8 исчезает.
• Включают JIT «для скорости» без замеров — получают нестабильность и лишний расход памяти вместо ускорения на веб-нагрузке.
• Не продумывают откат заранее — в момент аварии нет резервной копии и быстрого способа вернуть 7.4, и восстановление превращается в аврал.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность миграции перед выходом на прод:

1. Целевая версия выбрана. По «Проверке системы» определена поддерживаемая ветка PHP (как правило, 8.1 или 8.2); ядро и модули обновлены под неё.
2. Отчёт совместимости получен. «Проверка совместимости с PHP» запущена, устаревшие конструкции в ядре и коде выписаны в план правок.
3. Тестовый контур собран. Полная копия сайта развёрнута на целевом PHP 8, боевые интеграции переведены в тестовый режим, логи включены.
4. Кастом и модули починены. Кастомный код, старые модули Маркетплейса и шаблоны прогнаны и исправлены до чистого лога на ключевых сценариях.
5. opcache настроен. Выделена достаточная память, поднят лимит файлов, включено кэширование; JIT либо выключен, либо оставлен только после замеров.
6. Нагрузка пройдена. Нагрузочное тестирование подтвердило стабильность и прирост скорости против 7.4; opcache не переполняется.
7. Откат готов. Снята резервная копия, проверено, что возврат на 7.4 выполняется одной операцией; определён критерий отката.
8. Регресс на проде выполнен. После переключения проверены каталог, оформление заказа по всем способам оплаты и доставки, обмен с 1С; логи чистые.

Вывод

Миграция сайта на 1С-Битрикс на PHP 8 пугает ровно до тех пор, пока её пытаются сделать в один заход на боевом сайте. Разложенная на конвейер — тестовый контур, фикс кода, нагрузочное тестирование, прод с готовым откатом — она становится предсказуемой инженерной задачей. Ядро к PHP 8 готовят разработчики платформы, ваша зона ответственности — кастомный код, старые модули и шаблоны, а инструменты «Проверка системы» и «Проверка совместимости» подсказывают, где искать. Настройте opcache под размер проекта, не гонитесь за JIT без замеров, обязательно прогоните регресс каталога, заказов и обмена с 1С — и переход подарит сайту не только актуальную поддержку и безопасность, но и ощутимую прибавку в скорости.