Migrar WordPress a otro hosting sin perder la web ni el correo

Migrar WordPress a otro hosting consiste en copiar los ficheros y la base de datos al servidor nuevo, probar la web allí antes de tocar el DNS y cambiar el DNS al final, sin olvidar el correo. Hay dos cosas que se pasan por alto: los registros de correo y el orden en que se hacen los cambios.

Esta guía cubre el traslado de un hosting a otro (no de local a hosting). Incluye los pasos, los comandos de WP-CLI cuando sirven y lo que aprendimos en octubre de 2026 al trasladar 71 webs WordPress a un servidor nuevo. Si eres cliente de Blooglee, el traslado lo hacemos nosotros; te lo contamos al final.

Qué se mueve y qué no

En una migración se mueven cuatro cosas:

• Los ficheros de WordPress, sobre todo wp-content (tema, plugins e imágenes) y wp-config.php.
• La base de datos, donde viven las entradas, los ajustes y los usuarios.
• El DNS, que decide a qué servidor va el dominio.
• El correo, si lo tenías en el mismo hosting.

El dominio no se mueve. Sigue registrado donde estaba, y lo único que cambia es a dónde apunta. Ese detalle simplifica la migración: si la dirección de la web no cambia, no hay que reescribir URLs dentro de la base de datos.

La guía oficial de WordPress para mover un sitio lo dice así: si el dominio no cambia, se copian los ficheros y la base de datos y solo hay que actualizar wp-config.php si cambian las credenciales de la base de datos.

Plugin o manual: cómo elegir

Hay dos caminos. Con un plugin de migración es más rápido y suficiente para webs pequeñas o medianas. A mano es más controlable y es lo que usamos cuando la web es grande o cuando hay que repetirlo muchas veces. Los dos exigen lo mismo: copia previa, prueba antes de cambiar el DNS y cuidado con el correo. El resto de la guía describe el camino manual, porque es el que enseña qué pasa en cada paso.

Paso 1: copia completa y TTL

Haz una copia de ficheros y base de datos y guárdala fuera del servidor (en la guía de copias de seguridad tienes el procedimiento). Después, antes de cambiar nada, baja el TTL de los registros DNS. El TTL es el tiempo que los servidores de internet guardan en memoria dónde está tu web. Si es largo, el cambio tarda en llegar a todos.

Un valor corto como 300 segundos antes del cambio hace que el DNS nuevo se vea antes, y Route 53 recomienda empezar así y subir el valor cuando hayas confirmado que todo va bien. Esto no es instantáneo: tienes que bajar el TTL con antelación suficiente para que el valor antiguo caduque antes del día del cambio. No hay una cifra oficial; como criterio nuestro, bájalo al menos el tiempo que duraba el TTL anterior antes de migrar.

Anota también todos los registros DNS actuales. Lo vas a necesitar.

Paso 2: prepara el servidor nuevo

Crea la cuenta o el sitio en el hosting nuevo y comprueba que tiene una versión de PHP compatible con tu WordPress (en actualizar PHP en WordPress están las versiones vigentes). Crea una base de datos vacía y un usuario con permisos sobre ella.

Si tienes terminal en el servidor nuevo, WP-CLI te ahorra descargas. Para instalar un WordPress limpio en castellano:

wp core download --locale=es_ES
wp config create --dbname=NOMBRE_BD --dbuser=USUARIO --prompt=dbpass

Con --prompt=dbpass, WP-CLI te pide la contraseña de la base de datos en vez de dejarla escrita en el historial de comandos. Si solo vas a copiar tus ficheros encima, puedes saltarte esto.

Paso 3: copia los ficheros y la base de datos

Ficheros. Con acceso SSH a los dos servidores, rsync copia solo lo necesario y se puede repetir:

rsync -az --progress -e ssh usuario@origen:/ruta/web/ /ruta/destino/

No uses --delete en la primera pasada: borraría en destino lo que no esté en origen. Para ver qué haría sin tocar nada, añade -n (simulación). Sin SSH, descarga por SFTP y vuelve a subir.

Base de datos. En el servidor de origen:

wp db export copia-bd.sql

Copia el fichero al servidor nuevo y, con la base de datos ya creada, impórtalo:

wp db import copia-bd.sql

wp db import no crea la base de datos: tiene que existir. Si has cambiado el nombre, el usuario o la contraseña de la base de datos, actualiza wp-config.php con los nuevos datos.

Paso 4: cambia las URLs solo si el dominio cambia

Si migras con el mismo dominio, sáltate este paso. Si cambia (por ejemplo de viejo.es a nuevo.es), hay que reescribir las URLs que quedaron guardadas dentro de la base de datos. Un buscar y reemplazar de texto normal puede romper datos serializados, que guardan la longitud de cada cadena. WP-CLI sabe manejarlo:

wp search-replace 'https://viejo.es' 'https://nuevo.es' --skip-columns=guid --dry-run

Con --dry-run ves cuántos cambios haría sin aplicarlos. Si el resultado es el esperado, repite el comando sin esa opción. El --skip-columns=guid evita tocar el campo guid, que no debe modificarse nunca (documentación de WP-CLI). Después, regenera los enlaces permanentes y limpia la caché:

wp rewrite flush
wp cache flush

Paso 5: prueba la web nueva antes de cambiar el DNS

Para ver la web en el servidor nuevo sin tocar el DNS, edita el fichero hosts de tu ordenador y apunta el dominio a la IP del servidor nuevo. Las rutas son (según SW Hosting):

• Windows: C:\Windows\System32\drivers\etc\hosts
• macOS: /private/etc/hosts
• Linux: /etc/hosts

Añade una línea como 203.0.113.10 tudominio.com www.tudominio.com (con la IP real de tu servidor nuevo) y guarda. Solo tú verás la web nueva; el resto del mundo sigue viendo la vieja. Borra esa línea al terminar la prueba, o te olvidarás de que estás viendo el servidor nuevo.

Comprueba con calma:

• La portada, una entrada, una página interior y las imágenes.
• Los enlaces permanentes.
• El acceso al escritorio.
• Los formularios, incluido el envío del correo.
• Si hay tienda: un pedido de prueba y la pasarela de pago.

Paso 6: cambia el DNS sin romper el correo

Este es el paso donde conviene ir más despacio. Antes de cambiar nada, revisa todos los registros de tu zona DNS, no solo el de la web:

• Registro A de la web y, si existe, de www.
• Registros MX, que dicen a dónde va el correo (qué es un MX).
• Registros TXT de SPF, DKIM y DMARC, que firman y autorizan el correo saliente.
• Un registro A tipo mail o similar, si usas webmail propio.

Hay dos formas de hacer el cambio. Si solo cambias el servidor de la web, modifica el registro A y deja todo lo demás igual. Si cambias de servidores DNS (nameservers, por ejemplo a Cloudflare), el correo depende de que hayas copiado todos los registros a la zona nueva. Cloudflare lo advierte en su documentación: el escaneo automático no garantiza encontrarlos todos, así que revísalos a mano contra la lista que anotaste. Y si el dominio tiene DNSSEC activado, desactívalo en el registrador antes de cambiar los nameservers y vuélvelo a activar después.

Haz el cambio en una hora tranquila, y comprueba la web y el correo (enviando y recibiendo) en cuanto lo apliques.

Paso 7: certificado SSL

El certificado SSL de la web nueva también tiene que emitirse. Con Let’s Encrypt hay dos formas de demostrar que el dominio es tuyo (tipos de desafío):

• HTTP-01: el servidor responde a una petición en /.well-known/acme-challenge/ del puerto 80. Solo funciona cuando el dominio ya apunta al servidor nuevo.
• DNS-01: se crea un registro TXT en _acme-challenge. Funciona antes de cambiar el DNS de la web.

Si tu hosting emite el certificado solo, comprueba tras el cambio que el candado aparece. Si no, y usas HTTP-01, el certificado se pedirá cuando el DNS ya apunte al servidor nuevo, y puede haber un momento en que el navegador avise de que el certificado no es válido.

Paso 8: verifica y mantén el hosting viejo un tiempo

Cuando el DNS ya apunta al servidor nuevo, repite las comprobaciones del paso 5, esta vez sin el fichero hosts. Mira el correo, el escritorio, los formularios y los pedidos.

No canceles el hosting viejo enseguida. Si algo falla, tienes dónde volver. Mientras tanto, evita publicar contenido nuevo en uno u otro, para no tener datos en los dos sitios. Cuando lleves unos días sin incidencias, dale de baja.

Lo que aprendimos trasladando 71 webs

Entre el 26 de octubre y el 1 de noviembre de 2026 trasladamos 71 cuentas WordPress a un servidor nuevo. Las lecciones más útiles:

• El DNS es el punto frágil. Cambiamos el DNS de 71 dominios a Cloudflare y tuvimos que revertir cuatro de esos cambios. Por eso conviene tener apuntados los registros originales antes de empezar: permiten volver a un estado conocido.
• El correo va aparte. Lo movimos a un proveedor de correo independiente de la web. Así el correo no depende del servidor web.
• Migrar también es revisar. Aprovechamos para poner al día PHP y revisar cada sitio, y por el camino retiramos ficheros sensibles que estaban expuestos (copias .sql y un CSV de pedidos a la vista).

Preguntas frecuentes sobre migrar WordPress

Si prefieres que lo hagamos nosotros

Una migración bien hecha lleva tiempo y tiene muchos detalles que se olvidan. Si contratas Blooglee, de MKPRO, el traslado lo hacemos nosotros. Consulta los planes en precios y cómo es nuestro hosting WordPress. Para ver todo lo que hay que mantener después, tienes la guía de mantenimiento web, y si la migración viene de un susto, la de seguridad en WordPress.

Fuentes citadas

• Guía oficial para mover un sitio WordPress: https://developer.wordpress.org/advanced-administration/upgrade/migrating/ (consultada el 2 de noviembre de 2026)
• WP-CLI, wp search-replace: https://developer.wordpress.org/cli/commands/search-replace/
• Fichero hosts en Windows, macOS y Linux: https://www.swhosting.com/es/comunidad/manual/modificar-fichero-hosts-en-windows-mac-y-linux
• TTL en Route 53: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html
• Cloudflare, configuración de zona completa y DNSSEC: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/
• Registro MX: https://www.cloudflare.com/learning/dns/dns-records/dns-mx-record/
• Let’s Encrypt, tipos de desafío: https://letsencrypt.org/docs/challenge-types/