Migración de WordPress Sin Tiempo Fuera, Paso a Paso

La mayoría de la gente se queda en un hosting que ya se le quedó chico porque espera que mudarse signifique una caída. No es así, pero solo si la secuencia es la correcta.

La idea central: el sitio nuevo queda funcionando y probado antes de que algo apunte hacia él. El DNS es el último paso, no el primero, y es un cambio de interruptor, no una caída.

Paso 0: baje el TTL, con días de anticipación

Este es el paso que la gente se salta, y es el que decide si el “sin tiempo fuera” es real.

Sus registros DNS tienen un Time To Live: cuánto tiempo los guardan en caché los servidores que resuelven nombres. Si su registro A tiene un TTL de 24 horas, algunos visitantes seguirán llegando al servidor viejo durante un día entero después de que haga el cambio.

Al menos 48 horas antes de la migración, baje el TTL de sus registros A y CNAME a 300 segundos. Los resolutores necesitan tiempo para que expire el TTL largo anterior antes de empezar a respetar el corto — por eso hacer esto el día de la migración no sirve de nada.

Devuélvalo a un valor normal (3600 o más) una semana después del traslado.

Paso 1: copie todo al servidor nuevo

Archivos y base de datos, completos. La cuenta nueva debe ser una copia funcional completa — plantillas, plugins, archivos subidos y la base de datos — no una instalación limpia que se reconfigura a mano.

En este punto el sitio existe en dos lugares. El que está en producción sigue intacto y atendiendo tráfico.

Paso 2: pruebe en el servidor nuevo antes del DNS

Aquí es donde la gente se equivoca: cambia el DNS “para ver si funciona”.

Puede llegar al servidor nuevo sin DNS anulándolo localmente. Edite el archivo hosts de su computadora:

# macOS / Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.10   sudominio.com www.sudominio.com

Su navegador ahora resuelve el dominio hacia el servidor nuevo mientras el resto del mundo sigue llegando al viejo. El sitio carga bajo su nombre de dominio real, así que nada se rompe por una dirección temporal.

Pruebe en serio:

• Portada y varias páginas internas
• Inicie sesión en /wp-admin y guarde una entrada
• Envíe un formulario de contacto y confirme que llegue el correo
• Si es tienda: agregue al carrito, llegue al pago, complete un pedido de prueba
• Revise la consola del navegador por contenido mixto o errores 404
• Confirme que los enlaces permanentes resuelvan, no solo la portada

Quite la entrada del archivo hosts cuando termine.

Paso 3: instale el certificado antes del cambio

El certificado tiene que existir en el servidor nuevo antes de que llegue el tráfico, o los visitantes se topan con una advertencia de seguridad en el intervalo.

La validación HTTP estándar necesita que el dominio ya apunte al servidor: un problema del huevo y la gallina. Dos formas de resolverlo:

• Validación por DNS — usted demuestra control con un registro TXT, lo cual funciona antes de mover nada.
• Emisión previa a nivel de proveedor — la mayoría de proveedores administrados, HOSTEMCLOUD incluido, pueden emitir el certificado para un dominio alojado en la cuenta antes del cambio de DNS.

Confirme que el HTTPS funcione usando su anulación del archivo hosts. Si no funciona, no siga. Más sobre la mecánica de certificados en conceptos básicos de SSL/TLS.

Paso 4: congele el contenido y vuelva a sincronizar la base de datos

El hueco que se come datos: entre su copia de la base de datos y el cambio de DNS, la actividad real continúa en el servidor viejo. Pedidos nuevos, comentarios, formularios, entradas.

Para un sitio informativo, basta con dejar de editar durante una hora.

Para cualquier cosa con transacciones, haga una sincronización final de la base de datos justo antes del cambio:

1. Ponga el sitio viejo en modo mantenimiento, o simplemente acepte una ventana corta de solo lectura
2. Exporte la base de datos otra vez
3. Impórtela sobre la copia del servidor nuevo
4. Cambie el DNS

La ventana es de minutos, y el sitio se mantiene arriba todo el tiempo: brevemente de solo lectura, no fuera de línea.

Paso 5: cambie el DNS

Cambie el registro A a la IP nueva. Con un TTL de 300 segundos, el mundo lo sigue en unos cinco minutos.

Ambos servidores están funcionando durante la transición. Los visitantes llegan a uno o al otro; los dos funcionan. Nadie ve un error.

Deje la cuenta vieja encendida al menos una semana. Este es el seguro más barato de todo el proceso. Si algo aparece al tercer día, el sitio viejo sigue ahí.

Paso 6: verifique después del cambio

Confirme que el tráfico de verdad esté llegando al servidor nuevo:

dig +short sudominio.com
curl -sI https://sudominio.com | grep -i "^server:"

Después revise lo que comúnmente se rompe después de un traslado:

• Correo. Si los registros MX apuntan a otro lado, confirme que no se tocaron. Si el correo estaba en el proveedor viejo, esa es una migración aparte: planifíquela explícitamente en vez de descubrirla.
• Cron. El cron de WordPress se dispara con las visitas; las tareas cron reales configuradas en el servidor viejo no se migran solas.
• Correo saliente. Los formularios de contacto y las confirmaciones de pedido a menudo dejan de salir en silencio porque el servidor nuevo envía desde otra IP. Haga una prueba real.
• Search Console. Si cambió la IP o el certificado, vuelva a verificar y reenvíe el sitemap.
• Reglas de redirección. Las reglas personalizadas de .htaccess no siempre viajan con una herramienta automática de migración. Revíselas.

Lo que de verdad sale mal

En la práctica, las fallas rara vez son la copia de archivos:

1. Nunca se bajó el TTL — una cola larga de visitantes en el servidor viejo por un día, repartiendo formularios y pedidos entre dos bases de datos.
2. Certificado ausente en el cambio — advertencias de seguridad durante la ventana.
3. Se olvidó el correo — el sitio se mueve, el correo se rompe, y nadie se da cuenta hasta que un cliente dice que nunca le respondieron.
4. URLs fijas en la base de datos — direcciones absolutas apuntando a un nombre de pruebas. Un buscar y reemplazar que respete la serialización lo arregla; un reemplazo SQL ingenuo corrompe los valores serializados.
5. Se apagó el servidor viejo demasiado pronto — elimina el respaldo justo cuando más sirve.

La versión corta

1. Baje el TTL a 300, al menos 48 horas antes
2. Copie archivos y base de datos
3. Pruebe con el archivo hosts, bajo el dominio real
4. Instale el certificado antes de cambiar
5. Sincronización final de base de datos y cambio del registro A
6. Verifique, deje el servidor viejo una semana, restaure el TTL

Hecho en ese orden, no existe un momento en el que el dominio no resuelva a nada.

---

La migración viene incluida en todos los planes de HOSTEMCLOUD y nosotros ejecutamos esta secuencia por usted, incluyendo el certificado previo al cambio y la sincronización final. Si viene posponiendo un traslado desde una cuenta saturada — ver VPS en la nube vs hosting compartido para saber si de verdad se le quedó chica — empiece con UNITY y nosotros hacemos el traslado.