# PHP 8.2: fin del soporte el 31 de diciembre de 2026, ¿cómo migrar WordPress y sus aplicaciones?

> Fin del soporte de PHP 8.2 el 31 de diciembre de 2026: compruebe su versión y prepare la migración de WordPress, WooCommerce o PHP a 8.4 sin interrupciones.

Desarrollo web · Mantenimiento y seguridad de PHP

## PHP 8.2: fin del soporte el 31 de diciembre de 2026, ¿cómo migrar WordPress y sus aplicaciones?

PHP 8.2 dejará de recibir mantenimiento después del 31 de diciembre de 2026. Versiones alternativas, auditoría de compatibilidad y método de migración de WordPress, WooCommerce o PHP personalizado.

![PHP-8-2-to-8-4-Migration-Guide.webp](https://sdx-development.com/media/News/PHP-8-2-to-8-4-Migration-Guide.webp?v=1793653640)

[Desarrollo web](https://sdx-development.com/es/noticias/desarrollo-web)Publicado el 2 de noviembre de 2026

**El 31 de diciembre de 2026, PHP 8.2 llegará oficialmente al final de su vida útil.** A partir del 1 de enero de 2027, esta rama ya no recibirá parches de seguridad del equipo de PHP. Para un sitio de WordPress, una tienda WooCommerce o una aplicación empresarial, la respuesta adecuada no es cambiar de versión a ciegas: es preparar una migración verificada, con una copia de seguridad, un entorno de preproducción y la posibilidad de volver atrás.

 

El sitio no dejará de funcionar automáticamente al llegar 2027. Sin embargo, mantener una versión sin soporte aumenta progresivamente la exposición a vulnerabilidades descubiertas después de esa fecha, salvo que un proveedor ofrezca un mantenimiento extendido específico y documentado. A continuación explicamos cómo identificar la versión que se utiliza realmente, elegir entre PHP 8.3, 8.4 y 8.5 y migrar sin improvisar en producción.

 

A tener en cuenta 

## Una fecha límite de seguridad, no un fallo programado

 

**PHP 8.2: fin del soporte el 31 de diciembre de 2026.** Para muchos WordPress recientes, **PHP 8.4 es una opción razonable**, mientras que PHP 8.5 puede ser adecuado en un entorno ya probado. La elección debe validarse con los temas, las extensiones, los módulos del servidor y los desarrollos personalizados.

 

**En este artículo** 

[La fecha límite](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#echeance) [¿Qué versión?](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#versions) [Comprobar PHP](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#identifier) [Método de migración](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#methode) [Caso de WordPress](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#wordpress) [Caso de WooCommerce](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#woocommerce) [Aplicaciones empresariales](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#applications) [Costes y plazos](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#cout) [Preguntas frecuentes](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#faq) [Fuentes](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4#sources)

 

## Por qué el fin del soporte de PHP 8.2 afecta a su sitio

 

Una versión de PHP atraviesa dos fases principales: un periodo de soporte activo, durante el cual se publican correcciones de errores y de seguridad, y después un periodo dedicado a los problemas críticos de seguridad. Al final del ciclo, deja de contar con el soporte oficial de la comunidad.

 

Según el [calendario oficial de PHP](https://www.php.net/supported-versions.php), **PHP 8.2 dejará de recibir mantenimiento después del 31 de diciembre de 2026**. Esto no significa que PHP se desactive automáticamente ni que WordPress deje de ser compatible de inmediato. El riesgo se debe a que ya no habrá futuros parches oficiales para esta rama, con posibles consecuencias para la seguridad, los requisitos de conformidad y el mantenimiento de la aplicación.

 

Punto de atención 

## «Fin de vida útil» no significa «sitio fuera de línea»

 

Su proveedor de alojamiento puede seguir ejecutando PHP 8.2 después de la fecha límite o proporcionar parches específicos como parte de una oferta de mantenimiento extendido. En ese caso, compruebe **la duración, el alcance y las condiciones de ese soporte**. No confunda una versión que todavía puede ejecutarse con una versión mantenida oficialmente por el proyecto PHP.

 

Esperar a la última semana de diciembre dificulta las pruebas y las intervenciones, sobre todo en una tienda en línea o un software de uso diario. Es preferible empezar el inventario en noviembre y reservar después una ventana de migración adecuada para su actividad.

 

## PHP 8.3, 8.4 o 8.5: ¿qué versión elegir en noviembre de 2026?

 

Las tres ramas son alternativas con soporte a PHP 8.2, pero no ofrecen el mismo horizonte. Estas son las fechas anunciadas por el proyecto PHP a 2 de noviembre de 2026.

 

| Versión | Soporte activo hasta | Soporte de seguridad hasta | En la práctica |
| --- | --- | --- | --- |
| **PHP 8.2** | 31/12/2024 | **31/12/2026** | Migración que se debe planificar |
| **PHP 8.3** | 31/12/2025 | 31/12/2027 | Solución provisional si es necesario |
| **PHP 8.4** | 31/12/2026 | 31/12/2028 | Opción pragmática para muchos sitios recientes |
| **PHP 8.5** | 31/12/2027 | 31/12/2029 | Horizonte más amplio, tras validar las dependencias |

 

**En WordPress, hay que distinguir entre la recomendación general y la compatibilidad real.** La página pública de requisitos de WordPress recomienda PHP **8.3 o superior**. La guía técnica para proveedores de alojamiento recomienda, por su parte, **PHP 8.4 o superior en producción**. La tabla oficial de compatibilidad indica que WordPress 7.1 funciona con PHP 8.4 y 8.5. Sin embargo, ninguna de estas indicaciones garantiza que todas las extensiones, los temas o los desarrollos a medida sean compatibles.

 

La regla para decidir es sencilla: **prefiera PHP 8.4 si su instalación es reciente y compatible**; considere PHP 8.5 cuando se hayan probado todos los componentes críticos; utilice PHP 8.3 como solución provisional si alguna dependencia todavía impide pasar a una rama más reciente. Evite elegir una versión solo porque aparezca en el panel del proveedor de alojamiento.

 

## ¿Cómo saber si su sitio utiliza PHP 8.2?

 

En un sitio de WordPress, abra **Herramientas > Salud del sitio > Información > Servidor**: la línea «Versión de PHP» indica la versión que ejecuta el sitio. En WooCommerce, también encontrará esta información en **WooCommerce > Estado > Entorno del servidor**.

 

También puede consultar el selector de PHP de su proveedor de alojamiento, que puede estar en cPanel, Plesk o un panel propio. Si tiene varios dominios o subdominios, compruebe cada entorno: no necesariamente utilizan la misma versión.

 

En una aplicación personalizada con acceso al terminal, estos comandos permiten examinar el entorno PHP *de línea de comandos*:

 

```
php -v
php -m
```

 

**Atención:** la versión que muestra ` php -v ` puede diferir de la que utiliza el servidor web (PHP-FPM, Apache o una configuración por sitio). Hay que identificar la versión que procesa las solicitudes HTTP en producción. Evite dejar accesible al público un archivo de diagnóstico que muestre toda la configuración de PHP.

 

## Migración de PHP 8.2 a 8.4: método en 7 pasos

 

## Lista de comprobación antes de cambiar de versión

 
1. **Inventariar** los sitios, las versiones de PHP, los temas, los plugins, las bibliotecas, las tareas programadas y las integraciones.
2. **Elegir** la versión de destino según los requisitos reales de los componentes y del alojamiento.
3. **Crear copias de seguridad** de los archivos y la base de datos y comprobar que se pueden restaurar.
4. **Clonar** la instalación en un entorno de preproducción, sin iniciar pagos reales ni envíos de correo.
5. **Cambiar** el entorno de preproducción a PHP 8.4 y consultar los errores, las advertencias y los registros.
6. **Probar** los procesos importantes, las extensiones y las comunicaciones con servicios externos.
7. **Desplegar** en una ventana controlada, supervisar y volver al estado inicial si no se cumplen los criterios de validación.

 

### 1. Hacer un inventario técnico

 

Anote la versión de WordPress o del framework, la lista de extensiones y temas con sus versiones, los módulos de PHP necesarios, las llamadas a API externas, los scripts automáticos y las personalizaciones. Un sitio informativo sencillo y una aplicación con decenas de dependencias no requieren las mismas pruebas.

 

### 2. Preparar las copias de seguridad y el plan de reversión

 

Haga copias de seguridad **de la base de datos y de los archivos**, incluidos los medios, la configuración y los componentes personalizados. Compruebe la fecha y la disponibilidad de una copia y que se pueda restaurar correctamente. En algunos proveedores de alojamiento, volver a la versión anterior de PHP puede ser rápido, pero eso no resuelve un problema causado por un cambio simultáneo en el código o los datos.

 

### 3. Reproducir el sitio en preproducción

 

En la medida de lo posible, utilice la misma configuración del servidor y las mismas extensiones de PHP que en producción. Aísle los servicios sensibles: pasarela de pago en modo de prueba, correos interceptados, claves de API adecuadas y tareas programadas controladas. Si el sitio almacena datos personales, proteja esta copia y limite su acceso.

 

### 4. Actualizar los componentes incompatibles

 

Antes de cambiar PHP, compruebe qué versiones de WordPress, WooCommerce, el tema y las extensiones son compatibles. Puede que algunas actualizaciones deban aplicarse y probarse en un orden concreto. Anote las versiones validadas para reproducir **la misma combinación** en producción, en lugar de acumular cambios sin probar.

 

### 5. Activar PHP 8.4 en preproducción y consultar los registros

 

Cambie la versión desde el panel de alojamiento o la configuración del servidor. Compruebe los módulos que se utilizan (` intl `, ` mbstring `, ` curl `, ` gd `, ` imagick `, ` zip `, según las necesidades) y los parámetros sensibles. Analice los errores fatales, las advertencias de obsolescencia y los registros de la aplicación. Los mensajes de obsolescencia no siempre bloquean el funcionamiento de inmediato, pero pueden indicar que hay que adaptar el código.

 

### 6. Probar las funciones de negocio, no solo la página de inicio

 

Compruebe el inicio de sesión, los formularios, las cargas de archivos, la búsqueda, las cuentas de cliente, la administración, los correos electrónicos, las automatizaciones, las llamadas a API y los procesos en segundo plano. Incluya los flujos propios de su sector. Que un sitio muestre la página de inicio sin errores no significa necesariamente que funcione correctamente.

 

### 7. Desplegar y supervisar

 

Planifique la intervención para un periodo de poca actividad, informe a las partes interesadas, haga una copia de seguridad reciente y aplique el cambio validado. Compruebe de inmediato las transacciones y tareas críticas, supervise los registros y tenga a mano el procedimiento de reversión. En una tienda, supervise también los pedidos creados durante la intervención para no sobrescribir datos nuevos si fuera necesario restaurar una copia.

 

## Caso práctico: migrar un sitio de WordPress a PHP 8.4

 

En un WordPress reciente, el trabajo comienza con **una comprobación de la compatibilidad del tema y las extensiones** y después con un ensayo en una copia del sitio. En el panel de administración, anote las versiones de PHP y del núcleo de WordPress. Actualice en el entorno de prueba las extensiones que tengan mantenimiento y compruebe las personalizaciones del tema hijo y los plugins desarrollados específicamente para el sitio.

 

A continuación, cambie el entorno de preproducción a PHP 8.4. Pruebe la publicación y edición de páginas, los formularios de contacto, la autenticación, la biblioteca de medios, el envío de correos, la búsqueda interna y las funciones específicas de las extensiones. Si un componente solo funciona con PHP 8.2, busque primero una versión corregida o una alternativa mantenida en lugar de desactivar controles de seguridad.

 

Para pasar a producción, reproduzca las versiones ya probadas y vuelva a comprobar **Herramientas > Salud del sitio**. Los sitios muy personalizados pueden requerir una auditoría de código adicional; su migración no se reduce a hacer clic en el panel de alojamiento.

 

## WooCommerce: pruebas indispensables antes del cambio

 

Una tienda no puede limitarse a comprobar que se muestran las fichas de producto. Después de migrar en preproducción, haga pruebas con un medio de pago de demostración: **ficha de producto, carrito, finalización del pedido, gastos de envío, impuestos, creación del pedido, correo transaccional y cambio de estado**. Compruebe las pasarelas de pago, las integraciones con ERP/CRM, las suscripciones si las hay y las acciones programadas.

 

WooCommerce recomienda PHP 8.3 o superior e insiste en las copias de seguridad y las pruebas en un entorno de preproducción. Para evitar perder pedidos, no sobrescriba automáticamente la base de datos de producción con una copia anterior al inicio de las ventas. La estrategia de reversión debe tener en cuenta los pedidos y pagos realizados mientras tanto.

 

## Aplicación PHP personalizada: comprobar también el código y Composer

 

En un software empresarial, una extranet o una API, la compatibilidad del framework no es suficiente: examine también las bibliotecas instaladas, las extensiones nativas, los scripts CLI, los workers, las integraciones y el código heredado. El archivo ` composer.lock ` permite saber qué dependencias están realmente instaladas.

 

En un entorno de preproducción que ejecute **la versión de PHP de destino**, una comprobación útil para un proyecto de Composer es:

 

```
php -v
composer check-platform-reqs --no-dev
```

 

Este comando compara la versión de PHP y las extensiones presentes con los requisitos de los paquetes instalados. No sustituye las pruebas automatizadas ni las pruebas de negocio, y debe ejecutarse con el intérprete de PHP correcto. Antes de cambiar producción, añada pruebas de regresión, revise los registros y compruebe los trabajos programados.

 

Las aplicaciones antiguas o las dependencias abandonadas pueden requerir correcciones de código, una actualización del framework o la sustitución de un paquete. En ese caso, lo adecuado es hacer **una auditoría de compatibilidad** y elaborar después un plan de migración por etapas, en lugar de estimar el trabajo basándose únicamente en el número de versión.

 

## ¿Cuánto cuesta migrar PHP 8.2 a 8.4?

 

Caso más sencillo 

### WordPress estándar y con mantenimiento

 

Cuando las extensiones están actualizadas y son compatibles, la mayor parte del trabajo consiste en hacer copias de seguridad, preparar la preproducción, cambiar de versión y validar las funciones. El tiempo depende del número de sitios y sus funcionalidades.

 

Caso más complejo 

### WooCommerce o aplicación empresarial

 

Una tienda con pagos, un tema personalizado o una aplicación con integraciones específicas requiere más escenarios de prueba y, en ocasiones, correcciones de código.

 

**No existe una tarifa universal** para esta migración. Antes de calcular el coste, hay que conocer la versión actual de PHP, el volumen de componentes que se deben revisar, si existe un entorno de preproducción, las funciones críticas, las limitaciones de disponibilidad y el posible trabajo de corrección. Un simple cambio en el alojamiento y una migración completa de la aplicación no son el mismo servicio.

 

Para una empresa, el objetivo es reducir el riesgo operativo y seguir utilizando una versión con soporte. Un diagnóstico inicial permite distinguir lo que se puede actualizar directamente de lo que requiere desarrollo o pruebas adicionales.

 

## Preguntas frecuentes: fin de vida útil de PHP 8.2

 

¿Mi sitio dejará de funcionar el 1 de enero de 2027?

 

No automáticamente. PHP 8.2 puede seguir ejecutando el código después del fin del soporte, pero el equipo de PHP ya no publicará parches oficiales para esta rama. Compruebe también la política de su proveedor de alojamiento.

 

¿Se puede pasar directamente de PHP 8.2 a PHP 8.4?

 

Sí, si su alojamiento, WordPress o framework, extensiones y código son compatibles. El entorno de preproducción y las pruebas son indispensables para confirmarlo.

 

¿Por qué no elegir siempre PHP 8.5?

 

PHP 8.5 tiene un horizonte de soporte más amplio, pero puede que algunas dependencias o extensiones requieran adaptaciones. La versión más reciente no siempre es el primer destino adecuado para una aplicación existente.

 

¿WordPress 7.1 es compatible con PHP 8.4 y 8.5?

 

Sí, según la tabla de compatibilidad del núcleo de WordPress. Esto no valida automáticamente los temas, plugins, módulos de alojamiento o desarrollos personalizados instalados en su sitio.

 

¿Puedo cambiar la versión de PHP desde WordPress?

 

Por lo general, no: WordPress permite consultar la versión utilizada, pero el intérprete de PHP se elige en el alojamiento o el servidor. Consulte las opciones con su proveedor de alojamiento.

 

¿Basta con una copia de seguridad para asegurar la migración?

 

Es indispensable, pero no sustituye una restauración probada, un entorno de preproducción representativo, la validación de las funciones de negocio y un plan de reversión que tenga en cuenta los datos creados mientras tanto.

 

## Preparar la migración antes de que termine el año

 

**El 31 de diciembre de 2026 es una fecha límite de seguridad conocida, no un motivo para modificar un sitio a toda prisa.** Identifique hoy su versión de PHP, compruebe la compatibilidad de los componentes, pruebe una versión con soporte en preproducción y planifique un cambio controlado. Para muchos sitios de WordPress, PHP 8.4 es un punto de partida adecuado; en una aplicación personalizada, el destino debe determinarse mediante una auditoría técnica.

 

SDX Development puede ayudarle con **una auditoría de compatibilidad con PHP, la migración de WordPress o WooCommerce y la adaptación de una aplicación empresarial**, con copias de seguridad, pruebas de regresión y un procedimiento de despliegue. Para conocer las futuras evoluciones del lenguaje, consulte también nuestro artículo [PHP 8.6: las pruebas que se deben realizar antes de noviembre](https://sdx-development.com/actualites/developpement-web/php-8-6-les-tests-a-mener-avant-novembre), dedicado a un tema distinto de este fin del soporte.

 

Fuentes oficiales y documentación técnica 7 referencias

 

- [PHP — Supported Versions](https://www.php.net/supported-versions.php): calendario del soporte activo y de seguridad, y fechas de fin de vida útil.
- [WordPress.org — Requirements](https://wordpress.org/about/requirements/): requisitos generales; se recomienda PHP 8.3 o superior.
- [WordPress Hosting Handbook — Server Environment](https://make.wordpress.org/hosting/handbook/server-environment/): recomendación de PHP 8.4 o superior en producción y requisitos de alojamiento.
- [WordPress Core — PHP Compatibility and WordPress Versions](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/): compatibilidad de WordPress 7.1.
- [WooCommerce — How to update your PHP version](https://woocommerce.com/document/how-to-update-your-php-version/): cómo comprobar PHP en WordPress y WooCommerce.
- [WooCommerce — How to update WooCommerce](https://woocommerce.com/document/how-to-update-woocommerce/): copias de seguridad, preproducción y escenarios de prueba para tiendas.
- [Composer — check-platform-reqs](https://getcomposer.org/doc/03-cli.md#check-platform-reqs): comprobación de los requisitos de PHP y de las extensiones de las dependencias instaladas.

DESARROLLO WEB

## Prepare la evolución de su aplicación web.

Migración de PHP, actualización de CMS o evolución de framework: identifique los puntos de compatibilidad y valide los recorridos esenciales antes de la puesta en línea.

- Compatibilidad de las dependencias verificada
- Recorridos esenciales probados en preproducción
- Puesta en línea con posibilidad de volver atrás

[Preparar su evolución](https://sdx-development.com/es/contacto)[Ver las expertises](https://sdx-development.com/es/servicios)

---

[Consultar la página HTML](https://sdx-development.com/es/noticias/desarrollo-web/fin-del-soporte-de-php-8-2-migracion-de-wordpress-y-php-8-4)
