Fin de soporte de PHP 8.2: cómo migrar tu sitio antes del 31/12

PHP 8.2 recibe su último parche de seguridad oficial el 31 de diciembre de 2026: desde el 1 de enero, el equipo de PHP deja de corregir fallas en esa versión, según el calendario oficial de versiones soportadas de php.net. Tu sitio no se apaga ese día, pero cualquier vulnerabilidad que aparezca después queda abierta para siempre. Si tu web en WordPress, tu tienda WooCommerce o tu sistema en Laravel corre sobre PHP 8.2 (o sobre 8.1, 8.0 o 7.x, que ya están sin soporte), tenés unas doce semanas para pasar a PHP 8.3 o superior, y conviene hacerlo con una prueba previa, no con un clic un viernes a la tarde.

Qué termina exactamente el 31 de diciembre#

PHP mantiene cada versión durante cuatro años: dos de soporte activo (corrige errores y fallas de seguridad) y dos más de soporte de seguridad (solo corrige problemas de seguridad críticos). Después, la versión llega a su fin de vida y, como explica php.net, quien siga usándola puede quedar expuesto a vulnerabilidades sin corregir.

Este es el estado de cada versión al 7 de octubre de 2026, según php.net:

La última actualización de PHP 8.2 es la 8.2.34, una versión de seguridad publicada el 24 de septiembre de 2026, el mismo día que las 8.3.35, 8.4.26 y 8.5.11, según la portada de php.net. Si tu hosting todavía te muestra una 8.2 más vieja, ni siquiera tenés los parches que siguen saliendo hasta diciembre.

Las versiones anteriores ya están fuera de juego: PHP 8.1 terminó el 31 de diciembre de 2025 (su última versión fue la 8.1.34), PHP 8.0 el 26 de noviembre de 2023 y PHP 7.4 el 28 de noviembre de 2022, según la lista de versiones sin soporte de php.net.

Cuántos sitios están en esta situación#

No es un problema de nicho. Según W3Techs, al 7 de octubre de 2026 PHP es el lenguaje del 69,8 % de los sitios cuyo lenguaje de servidor puede identificar. Dentro de los que usan PHP 8, W3Techs registra esta distribución:

Dicho de otro modo: la mitad de los sitios con PHP 8 (8.2, 8.1 y 8.0 suman 50,1 %) va a estar sin parches oficiales el 1 de enero. Y eso sin contar a quienes siguen en PHP 7, que según la misma medición son el 27,6 % de los sitios con PHP.

A qué versión conviene pasar#

La respuesta depende de qué tan actualizada esté la plataforma que corre encima de PHP. Saltar a la versión más nueva no sirve de nada si tu WordPress o tu versión de Laravel no la soporta.

Si tu sitio es WordPress#

WordPress recomienda PHP 8.3 o superior, aunque todavía funciona desde PHP 7.4 en entornos viejos (con la advertencia de que esas versiones ya no tienen soporte). La compatibilidad real depende de tu versión de WordPress, según la tabla oficial de compatibilidad, actualizada el 19 de agosto de 2026:

La regla práctica: primero actualizás WordPress, después PHP. Ojo, que la tabla habla del núcleo de WordPress: los plugins y el tema van por su cuenta, y son los que suelen fallar en un cambio de versión.

Si tu sistema está hecho en Laravel#

Laravel publica qué versiones de PHP soporta cada una de sus versiones, según su política de soporte:

Si tu proyecto está en Laravel 11, el problema es doble: el framework ya no recibe parches y PHP 8.2 los pierde en diciembre. En ese caso conviene planificar el salto a Laravel 12 o 13 junto con el cambio de PHP.

Entonces, ¿8.3, 8.4 u 8.5?#

• PHP 8.3 es el salto más corto y el que menos cambios trae, pero sus parches terminan el 31 de diciembre de 2027: en un año vas a estar haciendo esto otra vez.
• PHP 8.4 tiene parches hasta fines de 2028 y es compatible con WordPress desde la 6.7 y con Laravel 11 y 12. Para la mayoría de los sitios de pymes es el equilibrio razonable entre plazo y riesgo.
• PHP 8.5 da margen hasta 2029, pero exige WordPress 6.9 o superior y es la que menos sitios usan todavía, así que hay más chances de encontrar un plugin que no esté listo.

Un dato más para el calendario: PHP 8.6 está en etapa de prueba y su lanzamiento está previsto para el 19 de noviembre de 2026, según el cronograma publicado en la wiki de PHP. La propia portada de php.net aclara que sus versiones candidatas no son para producción.

Qué puede romperse en el cambio#

La mayoría de los sitios pasa de versión sin problemas visibles, pero cada salto tiene cambios incompatibles documentados. Si vas a PHP 8.4, estos son los que más suelen aparecer en sitios de pymes, según el anuncio oficial de PHP 8.4 y su guía de cambios incompatibles:

• Extensiones que dejaron de venir incluidas. IMAP, OCI8, PDO_OCI y pspell pasaron a PECL, el repositorio de extensiones aparte. Si algún plugin o sistema lee casillas de correo con las funciones IMAP de PHP (por ejemplo, para convertir mails en tickets o en pedidos), puede dejar de funcionar si el servidor no instala esa extensión por separado.
• Parámetros "nullables" implícitos marcados como obsoletos. Código escrito como Tipo $x = null sigue funcionando, pero genera avisos de obsolescencia. No rompe nada hoy, pero puede llenar los registros y es una señal de código que habrá que actualizar.
• exit() y die() cambiaron de comportamiento. Ahora se comportan más como una función: pasarles un tipo inválido lanza un error TypeError.
• Un código de error de MySQL cambió. El error por tiempo de espera agotado del servidor pasó de 2006 a 4031 en MySQL 8.0.24 o superior. Un sistema propio que detecte reconexiones buscando el 2006 deja de detectarlas.
• Funciones más estrictas. round(), str_getcsv() y varias funciones de imágenes de GD ahora lanzan errores ante valores inválidos que antes se toleraban.

Si venís de PHP 8.1 o anterior, sumá las guías de migración de cada salto intermedio, que php.net enlaza desde su tabla de versiones y desde la de versiones sin soporte.

El caso de los servidores propios con Debian#

Si tu sitio no está en un hosting compartido sino en un VPS o una máquina virtual en la nube, hay un matiz importante: muchas veces PHP no viene de php.net sino de los paquetes de la distribución Linux, que publica sus propias correcciones.

Debian 12 (bookworm), por ejemplo, trae PHP 8.2, y su registro de seguridad muestra el paquete 8.2.34-1~deb12u1 en el canal de seguridad. El soporte completo de Debian 12 terminó el 11 de julio de 2026 y ahora está en su etapa de soporte de largo plazo (LTS) hasta el 30 de junio de 2028, solo para algunas arquitecturas, según la página oficial de Debian. Al 7 de octubre de 2026, esa página no aclara qué paquetes puntuales cubre el LTS después de diciembre, así que antes de confiar en eso conviene confirmarlo con el equipo LTS de Debian o con quien administra tu servidor.

En cualquier caso, depender de los parches de la distribución es una forma de ganar tiempo, no de evitar la migración: tus plugins, tu tema y tus dependencias van a ir dejando de probar sus actualizaciones en PHP 8.2.

Qué hacer ahora#

1. Averiguá qué versión usa cada sitio#

En WordPress, entrá a Herramientas > Salud del sitio y abrí la pestaña Información: la sección del servidor muestra los datos de PHP. Si la versión está desactualizada, la pestaña de estado lo marca como un problema crítico de seguridad, según la documentación de WordPress. En otros sistemas, la versión aparece en el panel de tu hosting o, en un servidor propio, con el comando php -v.

Hacé la lista completa, incluidas la landing de una campaña vieja y el subdominio de pruebas: el sitio olvidado es el que nadie migra.

2. Actualizá la plataforma antes que PHP#

Llevá WordPress, el tema y los plugins a sus últimas versiones antes de tocar PHP, o la versión de Laravel a una que soporte la versión de PHP elegida. Si en tu sitio no tenés activadas las actualizaciones automáticas de plugins, ya te contamos cómo hacerlo cuando analizamos la falla explotada en Ninja Forms que crea administradores ocultos.

3. Probá en una copia, no en producción#

Clonar el sitio a un entorno de pruebas (muchos hostings lo ofrecen como "staging") y cambiar PHP ahí es la forma más segura. Si tenés acceso al código, la herramienta libre PHPCompatibility revisa el código con PHP_CodeSniffer y señala funciones obsoletas o eliminadas; con la opción testVersion le indicás la versión de destino (por ejemplo, 8.4-). Para WordPress existe un conjunto de reglas propio, PHPCompatibilityWP. Tené en cuenta que el propio proyecto aclara que su cobertura no es completa: complementa la prueba manual, no la reemplaza.

En la copia, recorré lo que da plata: el carrito, el checkout con tu medio de pago, los formularios de contacto, el envío de correos y cualquier integración con tu sistema de gestión.

4. Cambiá la versión en el hosting#

En hostings con cPanel, la herramienta MultiPHP Manager permite elegir la versión por dominio: marcás el dominio, elegís la versión en el menú PHP Version y hacés clic en Apply, según la documentación de cPanel. La misma guía advierte dos cosas: si la versión que necesitás no aparece, es porque no está instalada en el servidor o no está habilitada para tu cuenta, y si el administrador limitó la versión del dominio, no vas a poder volver atrás desde ese panel. Por eso conviene anotar la versión original y confirmar con el hosting cómo revertir antes de cambiar.

5. Mirá los registros durante la primera semana#

Después del cambio, revisá el registro de errores de PHP del hosting. Los avisos de obsolescencia no rompen el sitio, pero te dicen qué plugin o qué parte del código va a fallar en la próxima migración.

6. Dejá la próxima fecha agendada#

Si elegiste PHP 8.3, la próxima fecha límite es el 31 de diciembre de 2027; con 8.4, el 31 de diciembre de 2028. Pasa lo mismo con cualquier software: lo vimos con el fin de las actualizaciones de Exchange Server 2016 y 2019. Y si este mes estás revisando la infraestructura, sumá a la lista el cambio de la llave raíz del DNS del 11 de octubre.

Preguntas frecuentes#

¿Mi sitio deja de funcionar el 1 de enero de 2027?#

No. PHP 8.2 sigue andando igual; lo que se termina son las correcciones de seguridad oficiales. El riesgo aparece con la primera vulnerabilidad nueva que se descubra en esa versión, porque ya no va a tener arreglo de parte de php.net.

¿Mi hosting no me va a cambiar la versión solo?#

Depende del proveedor y del plan. Algunos lo hacen con aviso previo y otros dejan elegir la versión por sitio, como en el MultiPHP Manager de cPanel. Preguntale a tu proveedor si tiene un plan para PHP 8.2 y en qué fecha: es mejor que el cambio lo decidas vos, después de probar, y no que te lo apliquen sin aviso.

Estoy en PHP 7.4, ¿puedo saltar directo a 8.4?#

Se puede, pero es el salto con más riesgo, porque acumula los cambios incompatibles de 8.0, 8.1, 8.2, 8.3 y 8.4. Además, solo las versiones de WordPress desde la 6.7 soportan PHP 8.4. En esos casos conviene revisar el código contra cada guía de migración y probar con más cuidado, o evaluar si el sitio necesita una renovación más profunda.

Una tarea para antes de fin de año#

En Mark-Co Digital hacemos este tipo de migraciones con una copia de prueba, revisión de compatibilidad y un plan para volver atrás. Si tu sitio es WordPress, podemos encargarnos de la actualización de WordPress junto con el cambio de PHP; si es un desarrollo en Laravel, de la actualización del sitio y de su versión de Laravel; y si corre en un VPS o en la nube, de la actualización del servidor con nuestro servicio de cloud e infraestructura. Si no sabés por dónde empezar, escribinos con la dirección de tu sitio y te decimos qué versión usa y qué conviene hacer.

Fuentes#

• Supported Versions (php.net)
• Unsupported Branches (php.net)
• PHP: Hypertext Preprocessor, portada con las últimas versiones (php.net)
• PHP 8.4 Release Announcement (php.net)
• Backward Incompatible Changes, PHP 8.4 (manual de PHP)
• PHP 8.6 release schedule (wiki de PHP)
• Usage statistics of PHP for websites (W3Techs)
• Usage statistics of PHP version 8 for websites (W3Techs)
• Requirements (WordPress.org)
• PHP Compatibility and WordPress Versions (WordPress Core Handbook)
• Site Health Screen (documentación de WordPress)
• Release Notes y política de soporte (Laravel)
• php8.2 en el Security Tracker de Debian
• Debian 12 "bookworm" (debian.org)
• MultiPHP Manager for cPanel (documentación de cPanel)
• PHPCompatibility (GitHub)