Проблема: legacy PHP — это авария в замедленной съёмке
Legacy PHP-приложение обычно несёт сразу три риска: оно работает на версии PHP, больше не получающей патчей безопасности, оно общается с базой данных через расширения, которые современный PHP удалил, и оно живёт на единственном стареющем сервере, который никто не решается перезагрузить. Каждый прошедший месяц делает его более уязвимым и труднее переносимым, потому что институциональная память о том, как оно работает, стирается, пока поверхность атаки растёт. Инстинкт оставить всё как есть понятен и как раз он делает ситуацию опасной — чем дольше оно стоит, тем крупнее становится в итоге вынужденная миграция. Этот сценарий существует, чтобы сделать перенос осознанным и обратимым, а не аварийным.
Как cdn.com.tr это решает: современный runtime, управляемые данные, edge-защита
PHP Platform даёт приложению поддерживаемый runtime PHP 8 с нормальным файловым менеджером и выбором версии, так что вы больше не привязаны к тому, что было установлено на старой машине. Управляемая база данных снимает данные с этого хрупкого сервера и переносит их на обслуживаемый сервис MySQL с учётными данными, внедряемыми в runtime, а не вставляемыми в конфигурационные файлы. Перед обоими уровень edge терминирует TLS через Auto SSL и фильтрует трафик через WAF, так что даже код, предшествующий современным практикам безопасности, не подвергается прямому воздействию интернета. Вы модернизируете runtime и уровень данных, одновременно обворачивая всё это защитой, которой у оригинального приложения никогда не было.
Совместимость с PHP 8: работа, которая реально определяет исход переноса
Миграция стоит или падает на совместимости кода, так что именно сюда уходит реальное усилие. Legacy-приложения обычно используют удалённые функции mysql_*, полагаются на функции, удалённые или изменённые в PHP 7 и 8, предполагают нестрогое приведение типов, которое PHP 8 ужесточил, или зависят от расширений, больше не поставляемых по умолчанию. Запуск приложения на staging-копии нового runtime выявляет эти проблемы как конкретные ошибки, а не как сюрпризы в продакшне. Вы методично их исправляете — заменяете mysql_* на mysqli или PDO, заменяете удалённые функции, устраняете предупреждения — и тестируете заново, пока критические пути не станут чистыми. Только тогда запуск становится рутинным шагом, а не прыжком веры.
Миграция базы данных без повреждения данных
Перенос данных — то место, где тихий вред случается, если торопиться. Самая распространённая ловушка — кодировка символов: многие legacy-базы данных в latin1 или смешанной кодировке, и импорт их в цель utf8mb4 без осторожности превращает турецкие символы и другой не-ASCII текст в кашу, которую потом мучительно исправлять. Безопасный путь — импортировать в управляемую MySQL, явно сопоставить исходную кодировку и collation и проверить выборку реальных записей — особенно всё с акцентированным или нелатинским текстом — прежде чем доверять результату. Вы проверяете полный цикл чтения/записи на staging, так что к моменту переключения база данных — заведомо рабочая копия, а не обнадёживающая.
Staging и rollback: никогда не рискуйте живым трафиком
Дисциплина, делающая перенос legacy безопасным, в том, что продакшн продолжает работать нетронутым, пока новое окружение не докажет себя. Вы строите и тестируете всё на staging и держите старый хост живым и обслуживающим до окончания переключения. Снижение TTL DNS заранее означает, что переключение на edge — и обратно, если нужно — занимает минуты, а не часы. Если что-то ломается под реальным трафиком, чего не выявил staging, вы откатываете DNS на старый хост, исправляете проблему на staging и пробуете снова. Поскольку ничто в старом окружении не было уничтожено во время переноса, rollback — реальная опция, а не блеф.
Опционально: стандартизировать будущие деплои через GitHub
Как только приложение на платформе, вы можете подключить его репозиторий через GitHub Deploy, чтобы будущие изменения выходили через повторяемый пайплайн — установка Composer, сборка и шаги миграции, определённые один раз и выполняемые одинаково каждый раз. Это превращает разовую миграцию в постоянный, контролируемый процесс деплоя, что часто становится моментом, когда давно заброшенное приложение наконец получает поддерживаемый процесс релизов. Это опционально, но именно здесь спасательная миграция превращается в настоящую модернизацию, а не просто смену адреса.
Как настроить, шаг за шагом
Инвентаризируйте приложение и выберите целевой runtime
Составьте каталог версии PHP, расширений, cron-задач и путей файлов, от которых зависит приложение, затем создайте приложение PHP Platform, нацеленное на поддерживаемый runtime PHP 8. Отметьте всё, что использует удалённые функции или старые расширения MySQL, чтобы знать, какие изменения кода предстоят, прежде чем трогать продакшн.
Разверните staging-копию
Задеплойте код на платформу как staging-окружение и импортируйте копию базы данных, чтобы можно было прогнать приложение на новом runtime без какого-либо живого трафика. Отправляйте код через GitHub Deploy или файловый менеджер, и держите это окружение, пока миграция не будет доказана.
Перенесите базу данных на управляемую MySQL
Создайте управляемую базу данных, импортируйте свой дамп и убедитесь, что кодировка и collation совпадают с оригиналом (legacy-приложения часто в latin1 или смешанной кодировке). Направьте приложение на управляемую БД, используя предоставленные платформой учётные данные, а не жёстко их задавая, и проверьте чтение и запись на staging.
Исправьте совместимость и повторно протестируйте на staging
Проработайте проблемы PHP 8, всплывающие на staging — устаревшие функции, mysql_* в mysqli/PDO, более строгую обработку типов — пока приложение не заработает чисто. Протестируйте критические пути (вход, формы, админка, платежи) целиком на staging-URL, прежде чем кто-либо заговорит о запуске.
Подключите домен, Auto SSL и WAF
Перенесите домен в аккаунт CDN, дайте Auto SSL подготовить сертификат и включите WAF, чтобы старый код был защищён в тот момент, когда столкнётся с публичным интернетом. Держите origin доступным только через edge, чтобы сервер приложения никогда не был открыт напрямую.
Переключите DNS с готовым откатом
Переключите DNS на edge в тихое окно с заранее установленным низким TTL, так что если появится проблема, вы сможете быстро откатиться. Держите старый хост работающим и нетронутым, пока новое окружение не докажет себя под реальным трафиком, затем выведите его из эксплуатации.
Примеры сценариев
Давно работающий форум на PHP с истёкшим сроком поддержки переносится на PHP 8 и управляемую MySQL, разделы архива с интенсивным чтением кэшируются на edge, а WAF смягчает злоупотребления ботов.
Собственная CMS на PHP переносится на современный runtime как есть после исправлений совместимости, покупая годы безопасной работы без полного переписывания.
Инструмент для бизнес-процессов на PHP, работающий на единственной стареющей машине, переносится на управляемый runtime и базу данных, устраняя единую точку отказа, которая держала всех в напряжении.
Часто задаваемые вопросы
Моё приложение использует старые функции mysql_*. Заработает ли оно на PHP 8?
Не как есть — эти функции были удалены много лет назад. Миграция включает их замену на mysqli или PDO, что как раз тот тип проблемы, который staging выявляет как явные ошибки, чтобы вы могли исправить их до запуска, а не обнаружить в продакшне.
Как избежать искажения турецких символов при переносе базы данных?
Явно сопоставьте исходную кодировку и collation при импорте в управляемую MySQL и проверьте выборку записей с акцентированным или нелатинским текстом на staging. Несовпадения кодировок — самый распространённый тихий сбой в legacy-миграциях, поэтому вы проверяете это до переключения, а не после.
Могу ли я всё протестировать, не трогая живой сайт?
Да, это суть подхода. Вы запускаете полную staging-копию на новом runtime с копией базы данных, доказываете критические пути, и только потом переключаете DNS. Продакшн всё это время продолжает работать на старом хосте.
Что если что-то ломается сразу после переключения?
Вы откатываете DNS обратно на старый хост, который всё ещё работает и не тронут, затем исправляете проблему на staging и пробуете снова. Установка низкого TTL DNS перед переключением держит этот откат в пределах минут.
Нужно ли обновлять весь код сразу?
Нужно достаточно работы по совместимости, чтобы приложение чисто работало на целевом runtime PHP 8, но переписывать приложение не обязательно. Многие legacy-приложения переносятся с сфокусированным набором исправлений; более крупный рефакторинг может произойти позже, когда приложение уже безопасно на платформе.
Безопасен ли мой старый код, когда он снова открыт для интернета?
Edge WAF и Auto SSL стоят перед приложением, фильтруя типовой атакующий трафик и обеспечивая HTTPS до того, как запросы достигнут origin. В сочетании с тем, что сервер приложения доступен только через edge, это даёт legacy-коду защиту, которой у него никогда не было на старом хосте.