PHP 8.2 llega a su fin de soporte: el plan de migración que te conviene tener armado

El calendario que define tu 2027

Según la tabla oficial de versiones soportadas de PHP, hay dos fechas que deberías tener en el calendario: el 31 de diciembre de 2026 PHP 8.2 termina su soporte de seguridad y queda sin mantenimiento, y ese mismo día PHP 8.4 deja el soporte activo para pasar a recibir solo parches críticos.

En paralelo, PHP 8.3 ya salió del soporte activo a fines de 2025 y PHP 8.5, liberado el 20 de noviembre de 2025, es la rama estable actual. Además, PHP 8.6 está en fase de release candidate. Traducido a la vida real de una empresa: si tu sitio corre en 8.2, en pocas semanas cualquier vulnerabilidad que aparezca en esa rama ya no se va a corregir.

Qué implica "fin de soporte" en la práctica

Un sitio web no se rompe el 1 de enero. Se degrada de otra manera.

1. Parches de seguridad que no llegan

Cuando una rama llega a fin de vida, el equipo de PHP deja de publicar correcciones, incluso para fallas graves. Tu hosting sigue funcionando, pero cada aviso de seguridad que aparezca queda sin respuesta del lado del lenguaje.

2. Dependencias que te arrastran

Laravel, Symfony y la mayoría de los frameworks modernos fijan una versión mínima de PHP. Cuando el framework sube el piso, el proyecto queda congelado: no podés tomar la última versión del framework, ni sus parches, porque el runtime no lo soporta.

3. Extensiones y librerías con mantenimiento

Las extensiones de imagen, las librerías de PDF y los SDK de pagos también van dejando atrás las ramas viejas. Ahí aparece el clásico "actualizamos todo y se rompió el checkout".

4. Costos de infraestructura

Muchos paneles de hosting cobran más por imágenes con versiones viejas, o directamente las retiran del catálogo. La versión del lenguaje termina siendo una decisión de factura mensual.

Por qué migrar de a saltos es más caro

El error más común es saltar directo de 8.2 a 8.5 y esperar que todo compile. Entre 8.2 y 8.5 hay cambios de deprecación, comportamientos nuevos y librerías que dejaron de existir. Hacerlo en un solo paso convierte una migración controlada en una reescritura de emergencia.

Conviene tratar la actualización como un proyecto con fases, igual que un plan de mantenimiento de Laravel bien armado: primero el diagnóstico, después la actualización del runtime con el código quieto, y recién al final el salto de framework.

Plan de migración en cinco etapas

Etapa 1: inventario real de versiones

No alcanza con mirar el archivo composer.json. Hay que revisar la versión efectiva del servidor, la de cada contenedor y la de los procesos que corren aparte (cron, colas, workers). Un mismo proyecto suele convivir con tres versiones distintas sin que nadie lo sepa.

Etapa 2: auditoría de deprecaciones

Correr los tests con el reporte de deprecaciones activado y clasificar: errores duros, avisos y código sin cobertura. La lista de deprecaciones es el verdadero backlog técnico de la migración.

Etapa 3: actualización en un entorno espejo

Levantar una copia del sitio con la versión nueva, con la misma base de datos anonimizada y el mismo tráfico sintético. Medir tiempos de respuesta antes y después: la migración también es una oportunidad de rendimiento.

Etapa 4: despliegue por capas

Primero un entorno de staging con usuarios internos, después un porcentaje de tráfico productivo si la arquitectura lo permite, y por último el corte completo. Con plan de rollback escrito y probado, no supuesto.

Etapa 5: cierre técnico

Actualizar la imagen base, fijar la versión en el pipeline, sacar del repositorio cualquier workaround de compatibilidad y documentar la fecha de la próxima revisión. Si el proyecto es a medida, esto se conversa mejor en el marco de desarrollo web a medida con Codit Suite.

Qué revisar antes de tocar el servidor

• Copia de seguridad verificada y restauración probada. No alcanza con que el backup exista.
• Lista de extensiones con versión nueva disponible.
• Compatibilidad del framework y de los SDK de pago con la versión destino.
• Pruebas de checkout completas: carrito, cupón, pago aprobado, pago rechazado y devolución.
• Monitoreo de errores activo antes, durante y después del corte.

Los tres escenarios típicos

Sitio institucional sin lógica de negocio: migración de horas, con riesgo bajo y ventana corta.

E-commerce con pasarela de pagos y facturación electrónica: riesgo medio. El punto crítico no es el núcleo del sitio, son las integraciones: cualquier cambio de comportamiento en la serialización o en las fechas afecta comprobantes y conciliaciones.

Sistema a medida con años de parches: riesgo alto. Acá la migración es una auditoría de deuda técnica disfrazada. Si el código no tiene tests, el primer entregable no es la versión nueva, es la red de seguridad.

El costo de no decidir

Postergar la actualización no es neutro. Significa convivir con librerías sin parches, no poder tomar releases de seguridad del framework y quedar expuesto a la primera vulnerabilidad pública del runtime. Es la misma lógica que ya se vio con los incidentes de PHP: cuando el parche existe pero no lo aplicás, el riesgo se traslada a tu operación, no al proveedor.

Próximo paso

Si tu sitio corre en PHP 8.2 o en una rama sin soporte activo, conviene llegar a diciembre con un plan y no con una urgencia. En Codit Digital hacemos auditoría de versiones, migraciones de runtime sin downtime y mantenimiento evolutivo sobre el servicio de desarrollo web a medida y Codit Suite. También podés pedir un diagnóstico desde contacto.