PHP 8.2 sin soporte el 31 de diciembre: qué hacer con tu Magento 2

PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si tu tienda Magento 2 funciona sobre esa versión, seguirá funcionando el 1 de enero, pero sin protección ante vulnerabilidades nuevas. Además, Adobe avisa de que el cumplimiento PCI corre riesgo desde finales de 2026. La solución depende de tu versión de Magento. En 2.4.7 basta con aplicar el último parche y pasar a PHP 8.3, sin cambiar de versión de Magento. En 2.4.6 no hay atajo: esa versión no admite PHP 8.3, así que primero tienes que actualizar Magento. Aquí tienes cómo saber en qué caso estás, a qué versión de PHP ir y cómo hacer el cambio sin parar las ventas en plena campaña de Navidad.

Qué pasa exactamente cuando PHP 8.2 llega al fin de soporte

Según el calendario oficial de versiones de PHP, PHP 8.2 terminó su soporte activo el 31 de diciembre de 2024. Desde entonces solo recibe correcciones de seguridad críticas, y también dejará de recibirlas el 31 de diciembre de 2026. Las fechas del resto de versiones:

Lo importante para tu negocio:

• Adobe no parchea PHP por ti. Su política de ciclo de vida dice que no da correcciones para dependencias de terceros que lleguen al fin de soporte. Mantenerlas en versiones soportadas es responsabilidad del comerciante.
• PCI DSS. Esa misma política relaciona PHP 8.2 con un riesgo para el cumplimiento PCI a partir de finales de 2026, y pide planificar la actualización antes. Si cobras con tarjeta, tu pasarela o tu auditor pueden preguntarte por ello. Lo mismo pasa con los escáneres de vulnerabilidades, que suelen marcar como fallo el software sin soporte.
• Tu tienda no se apaga. Nada deja de funcionar el 1 de enero. El riesgo va creciendo: cada vulnerabilidad nueva de PHP que se publique después de esa fecha se queda sin parche en tu servidor.

Un matiz: algunas distribuciones de Linux empresariales, como RHEL, AlmaLinux o Rocky, siguen dando parches a sus paquetes de PHP 8.2 durante años. Es soporte del fabricante del sistema operativo, no de PHP. Puede darte algo de margen, pero no lo uses como estrategia y confirma con tu auditor si le vale.

Cómo saber si tu Magento 2 está afectado por el fin de PHP 8.2

Necesitas dos datos: la versión de Magento y la versión de PHP que usa el servidor. Si tienes acceso SSH, o se lo pides a tu proveedor de hosting:

1. bin/magento --version: te dice la versión exacta de Magento, por ejemplo 2.4.7-p6.
2. php -v: te dice la versión de PHP de la línea de comandos, la que usa el cron.
3. Comprueba también la versión de PHP-FPM, la que sirve la web. Lo más fácil es mirarla en el panel del hosting (Plesk, cPanel) o crear temporalmente un phpinfo() protegido. Es un error habitual que la web y el cron usen versiones distintas de PHP.

Si no tienes acceso técnico, la versión de Magento aparece en el pie del panel de administración, y la de PHP en el panel de tu hosting.

Compatibilidad entre versiones de Magento y PHP

Estos son los requisitos de sistema publicados por Adobe para el último parche de cada versión:

Las fechas de soporte son las de Adobe Commerce. Para Magento Open Source, Adobe no publica una ampliación equivalente, así que cuenta con fechas iguales o más cortas.

Caso 1: tienes Magento 2.4.7 con PHP 8.2

Es el caso más fácil. Las notas de la versión 2.4.7 confirman que el núcleo y las extensiones de Adobe son compatibles con PHP 8.3. No hace falta cambiar de versión de Magento, pero sí:

• Aplicar el último parche de seguridad de 2.4.7 antes o a la vez que el cambio de PHP. Los requisitos de Adobe se refieren a los parches más recientes.
• Revisar las extensiones de terceros y el código a medida. La garantía de Adobe solo cubre su propio código. Pasarelas de pago, conectores con el ERP, módulos de transporte o filtros por capas son los que suelen dar problemas.
• Tener en cuenta la base de datos. MySQL 8.0 dejó de tener soporte el 30 de abril de 2026, y para 2.4.7 en servidor propio Adobe recomienda pasar a MariaDB 10.11 u 11.8. Si vas a tocar el servidor, aprovecha para revisarlo.

Ten presente que es una solución con fecha de caducidad. PHP 8.3 tiene parches hasta el 31 de diciembre de 2027, y 2.4.7 termina su soporte estándar en mayo de 2027. Te da margen para pasar la Navidad tranquilo y planificar en 2027 el salto a 2.4.8 o 2.4.9 sin prisas.

Caso 2: tienes Magento 2.4.6 (o anterior) con PHP 8.2

Aquí no puedes cambiar solo PHP: 2.4.6 no admite PHP 8.3. La única salida es actualizar Magento. Tienes dos opciones:

• 2.4.7 con PHP 8.3: el salto más corto, pero te deja con soporte solo hasta 2027.
• 2.4.8 con PHP 8.4: más trabajo ahora, pero te cubre hasta 2028 y te deja a un paso de 2.4.9.

Si vas a pagar una actualización de versión, normalmente compensa ir directamente a 2.4.8 o 2.4.9. Hacer dos migraciones en doce meses cuesta más que una bien hecha. Explicamos el proceso completo en nuestra guía para actualizar Magento 2.4.6 a 2.4.8 o 2.4.9 sin riesgos.

Si no llegas antes del 31 de diciembre, que es lo realista si empiezas ahora en plena campaña, la estrategia sensata tiene dos partes. Primero, refuerza la seguridad del entorno actual: WAF, último parche disponible de 2.4.6 y vigilancia de archivos modificados. Después, deja la actualización planificada para enero, con fechas cerradas.

Cómo actualizar PHP en Magento 2 paso a paso

Este es el proceso que seguimos para cambiar de versión de PHP en una tienda en producción:

1. Copia de staging idéntica a producción. Misma base de datos (anonimizada si hace falta), mismos módulos y misma configuración de Redis/Valkey, OpenSearch y Varnish.
2. Inventario de extensiones. Haz una lista de cada módulo de app/code y vendor que no sea de Magento y busca la versión compatible con PHP 8.3 u 8.4 de cada uno. Con composer prohibits php 8.3 ves qué paquetes bloquean el cambio.
3. Análisis estático del código a medida. Pasa PHP_CodeSniffer con el estándar PHPCompatibility, por ejemplo con --runtime-set testVersion 8.3, sobre tu código propio. Detecta funciones obsoletas antes de que fallen en producción.
4. Instalar la nueva versión de PHP con todas las extensiones que pide Magento: bcmath, intl, soap, sodium, xsl, zip, gd, sockets, entre otras. Copia también la configuración de php.ini: memory_limit, OPcache y realpath_cache_size.
5. Recompilar. Ejecuta composer install, bin/magento setup:upgrade, setup:di:compile y setup:static-content:deploy con la nueva versión de PHP.
6. Pruebas de negocio, no solo técnicas. Pedido completo con cada método de pago y de envío, alta de cliente, cupones, envío de pedidos al ERP, generación de facturas, correos transaccionales, importaciones y exportaciones de catálogo.
7. Revisar el cron y las colas. Comprueba que el crontab y los consumidores de colas llaman al binario de PHP nuevo y no al antiguo.
8. Despliegue en una franja de poco tráfico, con plan de vuelta atrás: la versión anterior de PHP sigue instalada y puedes volver a ella en minutos si algo falla.
9. Vigilar 48-72 horas. Revisa los logs de var/log, los errores de PHP-FPM, la tasa de conversión y los pedidos que no llegan al ERP.

Errores típicos al cambiar la versión de PHP en Magento

• Cambiar PHP desde el panel del hosting con un clic, directamente en producción. Es la causa más común de pantallas en blanco y checkouts rotos.
• Olvidarse del PHP de la línea de comandos. La web va bien, pero el cron sigue con 8.2, o falla, y dejan de enviarse correos, reindexarse productos o sincronizarse pedidos.
• Extensiones abandonadas. Si el fabricante de un módulo ya no saca versiones, toca sustituirlo o adaptarlo a mano. Conviene saberlo en el inventario, no la noche del despliegue.
• Hacerlo en Black Friday. Si tu tienda vive de noviembre y diciembre, decide ya si actualizas antes del pico o justo después, con las medidas de seguridad del caso 2 mientras tanto.

Cuánto se tarda en pasar Magento a PHP 8.3 u 8.4

Depende sobre todo de cuántas extensiones de terceros y cuánto código a medida tenga la tienda. Como referencia orientativa:

• 2.4.7 con pocas extensiones bien mantenidas: un cambio de PHP con parche incluido suele resolverse en pocos días de trabajo, contando las pruebas.
• 2.4.7 con muchas integraciones (ERP, PIM, marketplaces): de una a dos semanas, por la validación de cada conexión.
• De 2.4.6 a 2.4.8 o 2.4.9: es un proyecto de actualización completo, de varias semanas, sobre todo si hay tema personalizado o módulos sin mantenimiento.

Si llevas tiempo sin mantenimiento, lo más eficiente es empezar por una auditoría técnica de la tienda. Te dice qué extensiones sobran, cuáles hay que sustituir y cuánto trabajo real hay antes de comprometer fechas.

Preguntas frecuentes

¿Mi tienda Magento dejará de funcionar el 1 de enero de 2027 si sigo en PHP 8.2?

No. Seguirá funcionando igual, pero PHP dejará de publicar parches de seguridad para esa versión. Cualquier vulnerabilidad nueva quedará abierta, y tu situación de cara a PCI DSS empeora.

¿Puedo pasar mi Magento 2.4.6 a PHP 8.3 sin actualizar Magento?

No está soportado. Según los requisitos de Adobe, 2.4.6 solo admite PHP 8.1 y 8.2. Forzarlo puede romper partes del núcleo y te deja fuera de cualquier soporte.

¿Es mejor ir a PHP 8.3 o a PHP 8.4?

Depende de tu versión de Magento. En 2.4.7 el máximo es PHP 8.3. En 2.4.8 elige PHP 8.4, que tiene parches de seguridad hasta finales de 2028. Si planeas pasar a 2.4.9, que pide PHP 8.4 o 8.5, ir ya a 8.4 te facilita el siguiente salto.

¿Mi hosting puede cambiar la versión de PHP por mí?

Puede instalarla, pero no valida tu tienda. El hosting cambia el motor y tus extensiones, integraciones y checkout siguen siendo cosa tuya. Pruébalo siempre en un staging antes de tocar producción.

En resumen: con 2.4.7 tienes un cambio de PHP acotado que puedes hacer en pocos días. Con 2.4.6 te toca una actualización de Magento que conviene planificar ya. Si quieres que revisemos tu tienda, te digamos en qué caso estás y hagamos el cambio sin parar las ventas, nuestro equipo de desarrollo y mantenimiento Magento 2 se encarga de principio a fin. Y si ya lo has intentado y la tienda da errores después de cambiar de PHP, escríbenos a soporte urgente Magento Rescue y la recuperamos.