Una versión vieja de PHP es más lenta y, en cuanto sale del soporte de seguridad, deja de recibir arreglos para problemas que ya son públicos. Subir de versión suele ser indoloro; el riesgo viene de cambiar sin comprobar, y la comprobación son diez minutos.

Primero, averigüe qué se va a romper

composer require --dev php-parallel-lint/php-parallel-lint
vendor/bin/parallel-lint --exclude vendor .

Eso analiza cada archivo contra la versión en marcha y nombra todo lo que no vaya a compilar. No pilla los cambios de comportamiento, pero sí los de sintaxis, que son la mayoría.

Pruebe sobre una copia

  1. Copie el sitio a un subdominio de pruebas —
  2. Cambie ESE a la versión nueva — En EGPNL, sitio por sitio.
  3. Active los errores solo en pruebas — display_errors ahí, y nunca en producción.
  4. Recorra los caminos que importan — Inicie sesión, envíe un formulario, pague, ejecute a mano el script programado.

Qué suele romperse

  • Un plugin o una biblioteca abandonados que usan algo retirado hace años.
  • Pasar null donde se espera una cadena: una obsolescencia desde 8.1 que se vuelve ruido en el registro y no un error, pero mucho ruido.
  • Una extensión que no está instalada para la versión nueva: cada versión tiene su propio juego, y esta es la sorpresa más común.
php -m   # under the new version, compare against the old

Volver atrás

Devolver la versión desde el panel es instantáneo y no cambia nada más, así que el peor caso son unos minutos. Eso es lo que hace barato probarlo.

Mire el registro después de cambiar, no solo las páginas. Una obsolescencia escribe en cada petición y puede llenar un disco en un día aunque nada parezca roto.
Avance de una versión en una. De 7.4 a 8.3 de un salto le da todos los cambios a la vez y sin manera de saber cuál rompió qué.