Migrar WordPress de Bitnami a Lightsail: mucho más que actualizar PHP
Migrar WordPress de Bitnami a Lightsail no es solo actualizar PHP: te contamos los problemas reales que encontramos, cómo los resolvimos y qué aprendimos en el proceso.
Una actualización de seguridad que parecía sencilla terminó convirtiéndose en una migración completa de WordPress. Te contamos por qué, qué problemas encontramos y qué aprendimos durante el proceso.
Mantener actualizado el software de un servidor es una de las tareas fundamentales para garantizar su seguridad. Sin embargo, no todas las actualizaciones son tan sencillas como ejecutar un comando y reiniciar un servicio.
Recientemente nos encontramos con un caso que ilustra muy bien esta situación: una instalación de WordPress alojada en Amazon Lightsail utilizaba una versión de PHP afectada por vulnerabilidades de seguridad conocidas.
El objetivo inicial era sencillo: actualizar PHP a una versión corregida.
Pero había un detalle importante: WordPress estaba instalado mediante una imagen de Bitnami.
Y eso cambió considerablemente el procedimiento.
El problema: una versión de PHP vulnerable
El punto de partida era una instalación de WordPress que utilizaba PHP 8.2.28.
Aunque esta versión había recibido actualizaciones de seguridad en su momento, posteriormente se descubrieron vulnerabilidades que fueron corregidas en versiones más recientes.
Entre ellas destacan dos vulnerabilidades críticas publicadas en octubre de 2026:
- CVE-2026-109618: corrupción de memoria durante el tratamiento de solicitudes. Ver detalle
- CVE-2026-109619: reutilización de estados internos de PHP entre solicitudes. Ver detalle
Ambas podían permitir ejecución remota de código sin autenticación en determinadas circunstancias.
La actualización a PHP 8.2.35 incorporaba las correcciones necesarias para estas vulnerabilidades.
En una instalación convencional de Debian o Ubuntu, el procedimiento podría consistir en actualizar los paquetes correspondientes mediante el gestor del sistema.
Pero nuestra instalación tenía una particularidad.
¿Por qué Bitnami complicaba la actualización?
Bitnami permite desplegar aplicaciones como WordPress con una pila de software preconfigurada.
Estas imágenes incluyen componentes como:
- Apache.
- PHP.
- MariaDB.
- WordPress.
- Extensiones y herramientas auxiliares.
Una de sus ventajas es que permiten poner una aplicación en funcionamiento rápidamente, sin configurar cada componente individualmente.
Sin embargo, algunas imágenes de Bitnami utilizan instalaciones independientes de los paquetes del sistema operativo.
Por ejemplo, PHP puede encontrarse en:
/opt/bitnami/php/bin/phpEn lugar de utilizar:
/usr/bin/phpEsta diferencia tiene consecuencias importantes.
Ejecutar:
sudo apt update
sudo apt upgradeno necesariamente actualiza el PHP que utiliza WordPress.
Incluso instalando una versión nueva de PHP mediante APT, Apache podría continuar utilizando el PHP empaquetado por Bitnami.
Por tanto, actualizar PHP implica también revisar la configuración del servidor web, PHP-FPM, las extensiones y las dependencias de la pila.
Las alternativas
Ante esta situación, existen dos posibilidades principales:
1. Actualizar PHP dentro de la instalación Bitnami
Es posible instalar otra versión de PHP y modificar la configuración de Apache para utilizarla.
Sin embargo, esta alternativa requiere intervenir en diferentes componentes de la pila y comprobar cuidadosamente su compatibilidad.
2. Migrar WordPress a una instalación convencional
La otra alternativa consiste en crear una nueva instancia WordPress y trasladar los datos y archivos de la instalación original.
Esta fue la opción elegida.
No se trataba únicamente de resolver la vulnerabilidad actual, sino también de facilitar las siguientes actualizaciones.
La migración: del WordPress de Bitnami al WordPress de Lightsail
Amazon Lightsail ofrece imágenes de WordPress que no dependen del empaquetado tradicional de Bitnami.
En estas instalaciones, los componentes pueden gestionarse mediante los paquetes del sistema operativo, simplificando su mantenimiento.
La migración se organizó en varias fases.
1. Crear una nueva instancia
El primer paso consistió en desplegar una nueva instalación WordPress en Lightsail.
Antes de trasladar ningún dato, verificamos:
- La versión de PHP.
- El sistema operativo.
- El funcionamiento de Apache.
- La conexión con la base de datos.
- El espacio de almacenamiento disponible.
La nueva instancia utilizaba una versión corregida de PHP.
2. Respaldar la instalación original
Antes de modificar la infraestructura, generamos una copia de seguridad de la instancia original.
Además del snapshot del servidor, preparamos copias independientes de los componentes importantes de WordPress.
Principalmente:
- La base de datos.
- Los plugins.
- Los temas.
- Las imágenes.
- Los archivos de configuración relevantes.
Este último punto es especialmente importante.
Una exportación XML de WordPress no equivale a una copia completa de la instalación.
Puede permitir trasladar contenidos, pero no garantiza recuperar todas las configuraciones, personalizaciones y datos utilizados por los plugins.
3. Identificar los directorios reales de Bitnami
Durante el proceso encontramos otra particularidad: algunos directorios de WordPress estaban configurados mediante enlaces simbólicos.
Por ejemplo:
/opt/bitnami/wordpress/wp-contentpodía apuntar realmente a:
/bitnami/wordpress/wp-contentEsto es importante al realizar las copias de seguridad.
Si no se comprueba el destino real de los enlaces simbólicos, existe el riesgo de generar respaldos incompletos.
Para identificar la ubicación efectiva utilizamos herramientas como:
readlink -fY para comprobar el tamaño real:
du -shLLa lección es sencilla: antes de copiar una aplicación, hay que entender cómo está organizada realmente en el sistema de archivos.
4. Exportar e importar MariaDB
Una vez identificada la instalación, exportamos la base de datos mediante WP-CLI.
Esta herramienta permite administrar WordPress desde la terminal y resulta especialmente útil durante migraciones.
Por ejemplo:
wp db export backup.sqlEn la nueva instancia, restauramos la base de datos y comprobamos sus tablas.
wp db checkTambién verificamos la presencia de los contenidos y las configuraciones de los plugins.
Un detalle importante es que el nombre de la base de datos puede cambiar entre servidores.
Esto no representa un problema siempre que la nueva instalación tenga correctamente configuradas sus credenciales de conexión y se conserve la estructura de tablas correspondiente.
5. Restaurar plugins, temas y archivos multimedia
El siguiente paso fue trasladar el contenido de wp-content.
Este directorio contiene buena parte de los elementos que hacen que una instalación de WordPress sea única.
Después de restaurarlo, comprobamos:
wp plugin listwp theme listEstas operaciones permiten identificar:
- Plugins instalados.
- Versiones.
- Plugins activos e inactivos.
- Actualizaciones disponibles.
- Tema activo.
También es conveniente comparar los archivos mediante hashes para detectar diferencias entre las instalaciones.
No obstante, hay que tener en cuenta que los archivos de caché y otros datos generados automáticamente pueden cambiar mientras una web sigue funcionando.
Si te interesa saber cómo sustituir sistemas en producción sin parar el servicio, lee nuestro artículo sobre patrones de migración sin cortar el servicio.
Los problemas que aparecieron durante la migración
Migrar una aplicación no consiste únicamente en copiar sus archivos y su base de datos.
Las diferencias entre entornos pueden provocar comportamientos inesperados.
Durante el proceso encontramos varios ejemplos.
Problema 1. WordPress utilizaba 127.0.0.1 como URL
Después de importar los datos, WordPress seguía devolviendo una URL local:
http://127.0.0.1Al principio parecía un problema con las opciones home y siteurl almacenadas en la base de datos.
Sin embargo, aunque actualizábamos sus valores, WordPress continuaba utilizando la dirección anterior.
La causa estaba en wp-config.php.
La instalación incluía constantes que construían las URL utilizando la cabecera HTTP_HOST.
Esto permitía adaptar el dominio dinámicamente, pero producía resultados inesperados al ejecutar WordPress desde la línea de comandos.
La solución fue establecer explícitamente las URL correspondientes al dominio de producción.
Lección: cuando una configuración de WordPress parece ignorar los valores de la base de datos, conviene comprobar si existen constantes que los sobrescriben.
Problema 2. La página principal funcionaba, pero las demás devolvían 404
Este fue uno de los problemas más interesantes.
La página de inicio funcionaba correctamente, pero al acceder a determinadas páginas internas obteníamos:
404 Not FoundLa base de datos contenía las páginas y WordPress reconocía sus identificadores.
Sin embargo, Apache no interpretaba correctamente las URL amigables.
La causa estaba en las reglas de reescritura.
En la nueva instalación faltaba el archivo .htaccess con las reglas habituales de WordPress.
También era necesario comprobar que Apache tuviera habilitado mod_rewrite y permitiera aplicar las directivas correspondientes mediante AllowOverride.
Después de configurar las reglas, las páginas internas comenzaron a responder correctamente.
Lección: un código HTTP 200 en la página principal no significa que toda la aplicación funcione.
Después de una migración hay que verificar también las rutas internas.
Problema 3. El certificado HTTPS no era válido
La nueva instancia disponía inicialmente de un certificado autofirmado.
Esto permitía establecer conexiones cifradas durante las pruebas, pero los navegadores no podían verificar la identidad del servidor mediante una autoridad de certificación reconocida.
Para realizar pruebas antes del cambio de producción utilizamos la opción --resolve de curl.
Por ejemplo:
curl --resolve ejemplo.com:443:127.0.0.1 \
-k https://ejemplo.com/Esto permite probar una web contra una dirección IP concreta sin modificar los registros DNS públicos.
Usamos la opción -k exclusivamente durante las pruebas con el certificado provisional.
Para producción configuramos un certificado válido de Let’s Encrypt mediante las herramientas proporcionadas por Lightsail.
Problema 4. La existencia de IPv6
Otro aspecto que debía tenerse en cuenta era la configuración DNS.
El dominio tenía registros IPv4 e IPv6.
Aunque se trasladara correctamente la dirección IPv4, mantener un registro AAAA apuntando al servidor anterior podía provocar que algunos visitantes continuaran accediendo a la instalación antigua.
Por eso, durante una migración también es importante revisar:
- Registros A.
- Registros AAAA.
- Registros CNAME.
- Certificados HTTPS.
- Resolución DNS.
- Redirecciones entre dominios.
Especialmente cuando se pretende conservar el mismo dominio y minimizar las interrupciones.
Una migración también debe contemplar las tareas programadas
WordPress utiliza WP-Cron para ejecutar tareas como comprobaciones de actualizaciones, publicaciones programadas y procesos de determinados plugins.
Durante una migración es importante evitar que dos instalaciones ejecuten simultáneamente las mismas tareas.
Esto resulta especialmente relevante cuando existen:
- Procesos de envío de correo.
- Formularios.
- Integraciones externas.
- Acciones programadas.
- Plugins que realizan operaciones periódicas.
Por ello, controlamos la ejecución de WP-Cron durante la transición y la reactivamos cuando la nueva instalación asume el tráfico de producción.
En entornos donde la puntualidad de las tareas es importante, también recomendamos usar un cron del sistema operativo.
¿Qué aprendimos?
Esta experiencia deja varias conclusiones útiles.
1. No todas las instalaciones se actualizan igual
Que dos servidores utilicen Debian y WordPress no significa que tengan la misma estructura.
La forma en que se instalaron los componentes determina cómo deben mantenerse.
2. Las imágenes preconfiguradas tienen ventajas y limitaciones
Bitnami permite desplegar aplicaciones rápidamente.
Sin embargo, su empaquetado puede introducir dependencias y procedimientos de mantenimiento diferentes de los habituales en el sistema operativo.
Esto no convierte a Bitnami en una mala solución, pero es un factor que debe considerarse al elegir una arquitectura.
3. La migración debe verificarse funcionalmente
Comprobar que Apache funciona y que WordPress devuelve un HTTP 200 es solo el principio.
También es necesario revisar:
- Rutas internas.
- Imágenes.
- Formularios.
- Plugins.
- Temas.
- Configuraciones.
- Certificados.
- Tareas programadas.
4. Las copias de seguridad son parte del procedimiento
Un snapshot es útil, pero no sustituye necesariamente a una copia independiente de la base de datos y los archivos relevantes.
Tener diferentes mecanismos de recuperación facilita resolver incidencias durante la migración.
5. Hay que pensar en las próximas actualizaciones
Resolver una vulnerabilidad concreta es importante.
Pero también lo es evitar que la próxima actualización de seguridad vuelva a requerir una intervención compleja.
La facilidad de mantenimiento debe considerarse desde el diseño inicial de la infraestructura.
Conclusión: actualizar PHP puede implicar mucho más que actualizar PHP
Lo que inicialmente parecía una actualización puntual terminó requiriendo una migración completa de WordPress.
La razón principal fue el origen de la instalación: una imagen de Bitnami cuyo PHP estaba integrado en una pila de software independiente de los paquetes convencionales del sistema operativo.
Migrar permitió corregir la vulnerabilidad y adoptar una instalación más sencilla de mantener.
Pero también puso de manifiesto algo que a menudo se pasa por alto:
La seguridad no depende únicamente de tener software actualizado, sino también de contar con una arquitectura que permita actualizarlo de forma segura y predecible.
En Totbits trabajamos con esa filosofía: diseñar, mantener y evolucionar soluciones tecnológicas teniendo en cuenta tanto su funcionamiento actual como su mantenimiento futuro.
Porque una infraestructura bien planteada no es solamente la que funciona hoy. Es también la que podemos mantener segura mañana.
Referencias
Artículos relacionados
Migrar un sistema sin cortar el servicio
Los patrones que usamos para sustituir sistemas en producción que no se pueden parar: estrangulamiento progresivo, tráfico en sombra, sincronización de datos y vuelta atrás en minutos.