Cambiar tu web de servidor sin parar el negocio

Lo que sigue es para la persona que va a ejecutar la migración. Si no eres tú, pásaselo. Haz una copia completa antes de empezar y no cambies el DNS hasta haber probado la web nueva.

Cómo queda montado

Amazon Lightsail para WordPress. Lightsail es la versión simplificada de los servidores de AWS. Es una instancia con un tamaño fijo de CPU, memoria, disco y transferencia, y un coste mensual fijo. Su plano de WordPress (mantenido por Bitnami) trae Apache, PHP, MariaDB y WordPress instalados y configurados, con la web en /opt/bitnami/wordpress. Si el sitio crece, se cambia a una instancia mayor a partir de una instantánea, sin reinstalar nada.

S3 y CloudFront para el contenido estático. Las imágenes, los vídeos, las hojas de estilo y los scripts se guardan en un bucket privado de Amazon S3. Los sirve Amazon CloudFront, la CDN de AWS. Los copia en decenas de puntos del mundo y los entrega desde el más cercano al visitante. Delante de CloudFront se activa AWS WAF, un cortafuegos de aplicaciones que filtra el tráfico malicioso antes de que llegue a la web. Cómo montar esta CDN, paso a paso, está en la guía de velocidad de WordPress.

Lambda para tareas sueltas, no para WordPress. AWS Lambda ejecuta código sin servidor y se paga por ejecución. No sirve para alojar WordPress, que necesita un servidor siempre encendido. Sí sirve para tareas concretas alrededor de él: optimizar y convertir las imágenes que se suben al bucket, minificar ficheros o generar informes. Es una pieza opcional, útil cuando el volumen de imágenes es grande.

Herramientas para migrar el sitio

• All-in-One WP Migration: exporta todo el sitio (base de datos, medios, plugins y temas) a un único fichero que se importa en el destino. El más sencillo para sitios pequeños y medianos.
• Duplicator: crea un paquete completo del sitio más un instalador que lo despliega en el servidor nuevo. Muy usado para clonar.
• WP Migrate: especializado en la base de datos. La exporta reemplazando las URL y las rutas antiguas por las nuevas, que es el paso que más se olvida.
• UpdraftPlus: es un plugin de copias de seguridad que también restaura en otro servidor. Sirve para migrar y para las copias posteriores.
• Migrate Guru: automatiza la migración completa entre dos servidores sin pasar por tu ordenador. Útil para sitios grandes.

Un plugin puede sustituir los pasos 5 y 6 del camino manual que sigue.

Paso 1: evalúa el sitio actual

Antes de migrar nada, mira qué vas a migrar. Cuánto ocupan la base de datos y la carpeta de medios. Qué plugins están activos y cuáles se pueden borrar antes de la migración. Qué tema usa la web y si tiene código a medida. Es también el momento de limpiar: una base de datos sin revisiones antiguas ni spam se transfiere más rápido y arranca mejor en el destino. Anota cualquier cosa rara: tareas programadas, reglas en .htaccess, carpetas fuera de WordPress.

Paso 2: crea la cuenta de AWS y elige el servicio

Si no tienes cuenta en AWS, créala con un correo de la organización, no personal, y activa el segundo factor en el usuario raíz. Después decide dónde va a vivir WordPress. Para un sitio corporativo o una tienda mediana, Lightsail; para aplicaciones grandes con varios servidores y balanceo, EC2. Esta guía sigue el camino de Lightsail, que es el que recomendamos y el que usamos en nuestras migraciones. Elige una región de la Unión Europea si tus visitantes y tus datos están en Europa.

Paso 3: lanza la instancia

En la consola de Lightsail, «Crear instancia»: una región de la Unión Europea, plataforma Linux, plano «WordPress». Elige el tamaño según el sitio actual; se puede subir después, pero no bajar sin rehacer la instancia. Cuando esté en marcha, asígnale una IP estática desde la pestaña «Redes». Sin ella, la IP cambia al reiniciar y el DNS deja de apuntar a la web. Abre el cliente SSH del navegador o conéctate desde tu terminal con la clave que Lightsail te da. La contraseña inicial del administrador de WordPress está en el fichero bitnami_application_password de la carpeta de inicio.

Paso 4: prepara el sitio de origen

En el hosting actual, exporta la base de datos completa a un fichero .sql (desde phpMyAdmin o con mysqldump). Descarga la carpeta wp-content, que es donde viven los temas, los plugins y los medios. El núcleo de WordPress no hace falta copiarlo: la instancia ya lo trae. Si el sitio actual y el nuevo van a convivir unos días, anota la fecha de esta copia. Todo lo que se publique después habrá que volver a exportarlo, o congelar la publicación hasta el cambio de DNS.

Paso 5: transfiere los ficheros

En el plano de WordPress de Lightsail, la web vive en /opt/bitnami/wordpress, no en /var/www como en otros servidores. Es el error de ruta más repetido en tutoriales de migración. Copia tu wp-content a la instancia con SCP o rsync. Después devuelve los permisos que Bitnami espera, con el usuario bitnami y el grupo daemon:

rsync -avz wp-content/ bitnami@IP-DE-LA-INSTANCIA:/opt/bitnami/wordpress/wp-content/
sudo chown -R bitnami:daemon /opt/bitnami/wordpress/wp-content
sudo find /opt/bitnami/wordpress/wp-content -type d -exec chmod 775 {} \;
sudo find /opt/bitnami/wordpress/wp-content -type f -exec chmod 664 {} \;

Paso 6: crea la base de datos e importa la copia

La instancia trae MariaDB con una base de datos ya creada para el WordPress de muestra. Puedes reutilizarla o crear una propia, que es lo que hacemos para que el nombre y el usuario sean los tuyos. Entra en el servidor de base de datos con la contraseña de bitnami_application_password:

mysql -u root -p

CREATE DATABASE mi_web;
CREATE USER 'mi_usuario'@'localhost' IDENTIFIED BY 'una-contraseña-larga';
GRANT ALL PRIVILEGES ON mi_web.* TO 'mi_usuario'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Sube el fichero .sql a la instancia e impórtalo. Después usa WP-CLI, que el plano trae instalado. Reemplaza en toda la base de datos el dominio antiguo por el nuevo (o por la IP estática mientras pruebas). WordPress guarda URL absolutas en cientos de sitios:

mysql -u mi_usuario -p mi_web < copia.sql
cd /opt/bitnami/wordpress
wp search-replace 'https://web-antigua.com' 'https://www.mi-web.com' --all-tables

Paso 7: ajusta wp-config.php, cambia el DNS y prueba

Haz una copia del fichero de configuración y edítalo con los datos de la base de datos nueva:

cd /opt/bitnami/wordpress
sudo cp wp-config.php wp-config.php.backup
sudo nano wp-config.php

define('DB_NAME', 'mi_web');
define('DB_USER', 'mi_usuario');
define('DB_PASSWORD', 'una-contraseña-larga');
define('DB_HOST', 'localhost');

Comprueba también que el prefijo de tablas ($table_prefix) coincide con el de la base de datos importada. Reinicia los servicios con sudo /opt/bitnami/ctlscript.sh restart. Prueba el sitio por la IP estática. Mejor aún: edita el fichero hosts de tu ordenador para que el dominio apunte a la IP nueva, sin tocar el DNS todavía. Revisa la portada, una entrada, una página con formulario, el proceso de compra si lo hay y el panel de administración. Cuando todo funcione, cambia el registro A del dominio a la IP estática. Activa el HTTPS en la instancia con la herramienta bncert-tool de Bitnami, que lo configura y lo renueva sola. Si bajaste el TTL del DNS con un día de antelación, el cambio se nota en minutos.

Seguridad y costes: los ajustes concretos

En el cortafuegos de Lightsail deja abiertos solo los puertos 22, 80 y 443. Entra por SSH solo con clave, nunca por contraseña. Activa las actualizaciones y pon CloudFront con WAF delante de la web. Cambia las contraseñas de todo lo que se copió del sitio antiguo. En Lightsail el coste es fijo; lo que puede crecer es la transferencia de CloudFront y el almacenamiento de S3. Activa alertas de facturación en AWS desde el primer día.

Dónde están los logs

Cuando algo falla, los logs lo cuentan. En el plano de Bitnami están aquí:

• Accesos de Apache: /opt/bitnami/apache/logs/access_log
• Errores de Apache: /opt/bitnami/apache/logs/error_log
• Errores de PHP: /opt/bitnami/php/logs/php-fpm.log

Para ver las últimas líneas de uno de ellos mientras reproduces un error:

tail -n 100 -f /opt/bitnami/apache/logs/error_log

El correo saliente con SES

Una instancia de Lightsail no envía correo por sí misma. La opción natural dentro de AWS es Amazon SES. Se verifica el dominio con unos registros DNS y se crean credenciales SMTP. Después se configura WordPress con un plugin como WP Mail SMTP para que envíe a través de SES. Ten en cuenta que SES empieza en modo de pruebas, que solo entrega a direcciones verificadas, y hay que pedir la salida de ese modo. Si la organización ya usa Google Workspace o Microsoft 365 para el correo, los registros MX se quedan como están. Solo cambia el envío desde WordPress, que puede ir por SES o por el SMTP del proveedor.

Copias de seguridad con instantáneas

Lightsail hace copias de la instancia entera con instantáneas. En la página de la instancia, pestaña «Instantáneas», se crea una a mano con un nombre descriptivo, y se activan las instantáneas automáticas diarias. Lightsail conserva las últimas instantáneas automáticas; el número exacto lo indica tu consola. Una instantánea se restaura creando una instancia nueva a partir de ella. Por eso también sirve para cambiar de tamaño o para clonar un entorno de pruebas. Es una copia de servidor, no de contenido: para volver a una versión anterior de una sola entrada siguen sirviendo las revisiones de WordPress. Para guardar copias fuera de AWS, un plugin como UpdraftPlus enviándolas a otro almacenamiento. Tenemos una entrada dedicada a las copias de seguridad de WordPress en Lightsail. Y otra a montar un entorno de pruebas en Lightsail a partir de una instantánea.

Tareas programadas y Search Console

WordPress ejecuta sus tareas (publicaciones programadas, copias, envíos) cuando alguien visita la web. En un servidor propio es mejor lanzarlas desde el cron del sistema, cada cinco minutos, y desactivar el mecanismo interno en wp-config.php. Es un cambio pequeño que evita muchas caídas por picos de carga.

En Search Console, comprueba que Google sigue viendo el sitio, que el mapa del sitio responde y que no han aparecido errores de rastreo. Si el dominio no cambia, no hace falta nada más. Si cambia, hay que declarar el cambio de dirección y redirigir cada URL antigua a la nueva.