El riesgo real: dos bases de datos que se separan
Un sitio WordPress se compone de archivos, que se copian sin peligro, y de una base de datos, que cambia con cada visita: pedido, registro, comentario, entrada de formulario, carrito. En cuanto exporta la base, la antigua sigue escribiendo y la copia queda obsoleta. Mientras el DNS apunte al servidor antiguo, esa diferencia no se ve. El día del cambio se convierte en pérdida: todo lo llegado después de la exportación existe solo en el servidor antiguo.
El método cabe en una frase: montar y probar la copia con antelación, luego congelar las escrituras, hacer una última pasada de archivos y base, y solo entonces cambiar el DNS. El orden general de un cambio de hosting (TTL, correo, dominio) se trata en otra guía; esta se ocupa de lo propio de WordPress.
D-7: inventariar el sitio
Anote la versión de PHP, los plugins que escriben (tienda, formularios, reservas, suscripciones), las tareas programadas y las pasarelas de pago con sus direcciones de retorno.
wp core versionwp plugin list --status=activewp cron event list
Anote también dónde vive el correo: no se moverá.D-3: bajar el TTL
Ponga el TTL de los registros A y AAAA del sitio en 300 segundos, al menos un antiguo periodo de TTL antes del cambio. No toque los registros MX ni TXT.
D-2: primera copia completa
Archivos:
rsync -az --info=progress2 usuario@servidor-antiguo:/ruta/del/sitio/ /ruta/del/sitio/
Base de datos:wp db export site.sql --single-transactionen el servidor antiguo y despuéswp db import site.sqlen el nuevo. Cronometre ambos: esa duración dimensiona la ventana de congelación.D-2: aislar la copia
En la copia, añada
define('DISABLE_WP_CRON', true);awp-config.phpy desactive los correos de la tienda. La copia contiene clientes reales: un evento programado repetido enviaría mensajes duplicados.D-1: probar con el archivo hosts
Recorra la copia con su nombre real sin tocar el DNS público (sección dedicada más abajo). Anote cada anomalía, corrija y repita.
Día D, hora tranquila: congelar y tomar la última diferencia
Ponga el origen en mantenimiento con
wp maintenance-mode activate, repita la exportación de la base, resincronice los archivos con el mismo comandorsync, importe y vuelva a probar con hosts.Día D: cambiar el DNS y emitir el certificado
Sustituya los registros A y AAAA por las direcciones del nuevo servidor, sin tocar los MX. Emita el certificado en cuanto el nombre apunte al destino y retire después
DISABLE_WP_CRON.Día D a D+14: verificar, conservar, cortar
Revise los registros del servidor antiguo y la lista de comprobación de más abajo. Mantenga el servidor antiguo en mantenimiento, intacto, al menos dos semanas antes de darlo de baja.
Copiar archivos y base de datos y ajustar wp-config.php
Copie los archivos con rsync en lugar de un archivo comprimido subido a mano: conserva los permisos, se reanuda tras una interrupción y solo retransfiere lo que cambió, lo que hace muy corta la última pasada. Para la base, prefiera wp db export o mysqldump --single-transaction, que produce una exportación coherente sin bloquear las tablas InnoDB.
En el nuevo servidor, wp-config.php es el primer archivo que hay que releer. DB_NAME, DB_USER y DB_PASSWORD deben corresponder a la base creada en el destino. DB_HOST suele ser localhost, pero algunos hostings exigen un host distinto, un puerto (host:3307) o un socket. Compruebe también $table_prefix, que debe coincidir con el de las tablas importadas; si no, WordPress cree que la instalación está vacía. Por último, WP_HOME y WP_SITEURL, si están definidos en el archivo, prevalecen sobre la base: un valor antiguo olvidado aquí devuelve a cada visitante a la dirección anterior.
Reemplazar las URL en la base sin romper los datos serializados
WordPress guarda direcciones absolutas en las entradas, las opciones, los menús y los ajustes de temas y plugins, a menudo dentro de valores serializados cuya longitud está escrita en el propio dato. Un sed sobre la exportación cambia la longitud de la cadena sin corregir ese contador, y el valor se vuelve ilegible: widgets vacíos, tema restablecido. wp search-replace lee y reescribe correctamente estas estructuras.
El reemplazo solo es necesario si cambia la dirección: nuevo nombre de dominio, paso de http a https o copia montada bajo una dirección provisional. Si prueba con el archivo hosts bajo el nombre real, no hay nada que reemplazar. Empiece siempre con wp search-replace 'http://antiguo.su-dominio.com' 'https://su-dominio.com' --all-tables --skip-columns=guid --dry-run, que cuenta los reemplazos sin escribir nada. Si la cifra le sorprende, deténgase. Repita después sin --dry-run, en la copia y nunca en el origen, y ejecute wp cache flush. La opción --skip-columns=guid deja intactos los identificadores de las entradas, que los lectores RSS usan para reconocer un contenido ya leído.
Probar la copia antes del DNS con el archivo hosts
El archivo hosts de su equipo indica solo a su máquina adónde dirigir un nombre de dominio, sin tocar el DNS público. Añada una línea 203.0.113.10 su-dominio.com www.su-dominio.com (la dirección del nuevo servidor) en /etc/hosts, o en C:\Windows\System32\drivers\etc\hosts en Windows. Para una sola petición, curl --resolve su-dominio.com:443:203.0.113.10 -I https://su-dominio.com/ hace lo mismo sin modificar el equipo. Vacíe la caché del navegador, que conserva la resolución anterior.
Pruebe recorridos, no la página de inicio: acceso al administrador, una página profunda (que revela los enlaces permanentes), la subida de un archivo multimedia, la búsqueda y, en una tienda, un carrito hasta la página de pago. Puede que el certificado de la copia aún no esté emitido (véase más abajo): entonces es de esperar una advertencia, no una página en blanco ni un error de PHP. Retire después la línea de hosts: una entrada olvidada hace creer durante semanas que el cambio no ha ocurrido.
Congelar las escrituras en sitios con pedidos y formularios
Un sitio escaparate puede cambiar sin congelar nada: la posible pérdida se reduce a un comentario. En cuanto el sitio cobra o recoge solicitudes, hace falta una ventana sin escrituras. La secuencia: anunciar un mantenimiento breve, poner el origen en mantenimiento, repetir la exportación de la base, resincronizar los archivos (rsync solo transfiere ya la diferencia, a menudo solo los archivos multimedia añadidos), importar en el destino, repetir el search-replace si lo hay, probar con hosts y cambiar el DNS. El servidor antiguo permanece en mantenimiento hasta el final.
Esta ventana dura unos minutos en una base de tamaño habitual, y es una duración que conviene medir durante la primera copia. Las pasarelas de pago son un caso particular: envían sus notificaciones a la dirección configurada y reintentan las fallidas según su propia política, que debe confirmarse en su documentación. Compruebe en su panel que las notificaciones rechazadas durante el mantenimiento se reenvían cuando el nuevo sitio está en línea.
Qué escribe durante la ventana y cómo detenerlo
- Pedidos de WooCommerce — el mantenimiento del origen los bloquea; un cliente con el carrito ya abierto encuentra un sitio no disponible, de ahí el aviso previo.
- Formularios de contacto y de presupuesto — según el plugin, las entradas están en la base, en un archivo o solo se envían por correo; localice dónde escribe cada uno, porque una entrada guardada en el servidor antiguo tras la exportación se pierde.
- Comentarios y registros — ciérrelos en los ajustes de debate y de registro durante la ventana si no es posible el mantenimiento.
- Tareas programadas —
wp cron event listlas enumera; la copia no debe ejecutar las mismas que el origen antes del cambio, o los recordatorios y correos de renovación saldrán duplicados. - Webhooks entrantes — pasarelas de pago, CRM, herramienta de envíos: su dirección apunta a un nombre de dominio, es decir, al nuevo servidor tras el cambio; compruebe que los secretos de firma se copiaron con los ajustes.
- Visitantes que aún llegan al origen — un resolvedor con caché larga los envía allí tras el cambio; el servidor antiguo puede reenviarlos al nuevo conservando la cabecera
Host, algo reservado a equipos que dominan el proxy inverso.
Síntomas posteriores al cambio y su causa
Desplace la tabla
| Síntoma | Causa probable | Corrección |
|---|---|---|
| Bucle de redirección (`ERR_TOO_MANY_REDIRECTS`) | WordPress fuerza `https` pero solo ve `http`: un proxy, CDN o balanceador termina el TLS, o el modo SSL del CDN es Flexible | Modo Full (strict) en el CDN, o leer `X-Forwarded-Proto` en `wp-config.php` para definir `$_SERVER['HTTPS']` |
| Error establishing a database connection | `DB_HOST`, credenciales o permisos del usuario erróneos; servidor MySQL detenido | `wp db check`, luego prueba manual con `mysql -h host -u usuario -p`; conceder permisos sobre la base |
| Instalación vacía o pantalla de instalación | `$table_prefix` distinto del prefijo real de las tablas | Alinear el prefijo con el resultado de `SHOW TABLES` |
| Contenido mixto: candado tachado, imágenes bloqueadas | Direcciones `http://` que quedaron en las entradas u opciones | `wp search-replace` de `http://` a `https://`, tras un `--dry-run` |
| Entradas con 404, inicio correcto | Faltan las reglas de reescritura: `.htaccess` no copiado o no leído, o nginx sin `try_files` | `wp rewrite flush --hard`; en nginx, `try_files $uri $uri/ /index.php?$args;` |
| Menús, widgets o tema restablecidos | Valores serializados corrompidos por un reemplazo a ciegas | Reimportar la exportación y repetir el reemplazo con `wp search-replace` |
| Direcciones antiguas aún en las páginas | `WP_HOME` o `WP_SITEURL` fijados, o caché de página sin purgar | Corregir las constantes, `wp cache flush`, purgar la caché de página |
Correo y certificado: dos temas que no siguen al sitio
El hosting web y el correo son dos servicios distintos, apoyados en registros DNS diferentes: MX para la recepción, TXT (SPF, DKIM, DMARC) para el envío. Una migración web no debe modificar ni los MX ni los buzones. Compruébelo antes y después con dig MX su-dominio.com +short y dig TXT su-dominio.com +short: las dos salidas deben ser idénticas. La trampa está en el envío: si el SPF enumera la dirección del servidor antiguo (ip4:) y WordPress envía sus correos desde el nuevo, las notificaciones de pedido acaban en spam. Añada la nueva dirección al SPF o, mejor, haga pasar WordPress por un SMTP autenticado.
El certificado sigue a la dirección. Con validación HTTP (certbot --nginx o AutoSSL de cPanel), la autoridad de certificación debe llegar al nuevo servidor por el nombre real, lo que solo es posible tras el cambio: emítalo enseguida y espere una advertencia antes, incluso durante las pruebas con hosts. Si ese plazo es inaceptable, la validación por DNS permite emitir el certificado antes del cambio, a costa de un acceso API a la zona. Compruebe después el vencimiento con curl -vI https://su-dominio.com/ 2>&1 | grep -i expire.
Qué comprobar antes de cortar el servidor antiguo
- El tráfico ha cambiado de verdad — siga los registros de acceso del servidor antiguo con
tail -f: solo deben aparecer robots y resolvedores con caché larga, y luego nadie. - Las escrituras llegan al sitio correcto — haga un pedido con la pasarela en modo de prueba, envíe un formulario y localice ambos en la base y por correo.
- Los volúmenes son comparables — compare el número de filas de las tablas clave (
wp db query "SELECT COUNT(*) FROM wp_posts", adapte el prefijo) y el tamaño dewp-content/uploadscon el origen. - Las tareas programadas funcionan —
wp cron event run --due-nowdebe ejecutarse sin errores; configure un cron del sistema real si el tráfico es bajo. - El correo está intacto — MX, SPF y DKIM sin cambios, y un mensaje de prueba recibido en un buzón real.
- Existe una copia de seguridad final — exportación de la base y copia de los archivos del servidor antiguo, archivadas fuera de ese servidor, antes de apagar nada.
Decidir la vuelta atrás antes del cambio
La vuelta atrás es sencilla mientras el servidor antiguo siga intacto: se restablece la dirección antigua en los registros A y AAAA, con el TTL bajo ya aplicado. Deja de serlo en cuanto la nueva base ha recibido pedidos, porque volver atrás los borra. Fije por tanto la regla antes del día D: vuelta posible sin condiciones hasta la primera escritura real en el nuevo sitio, y corrección hacia adelante después. Mantenga el servidor antiguo intacto y pagado al menos dos semanas: es el precio de la reversibilidad.
En una cartera de clientes, el método se vuelve rutina
Escriba esta secuencia una vez, con las duraciones medidas, y reutilícela de un cliente a otro: ficha de inventario, ventana de congelación, lista de comprobaciones. El cliente no necesita entender el DNS; necesita saber cuándo será el mantenimiento y quién confirma que todo funciona. En ServOrbit, el hosting para revendedores agrupa las cuentas de sus clientes, y la migración asistida es una opción para los sitios que prefiera no mover usted mismo. Dominios, hostings y vencimientos se gestionan desde un solo espacio, con su marca.
