Migrar mi web a otro servidor sin que se caiga.

Esta es la secuencia. Saltarse un paso o cambiar el orden es de donde vienen casi todos los desastres:

• 1. Baja el TTL del DNS. Al menos 24 horas antes. Pon el TTL a 300 segundos. Así, cuando cambies la IP, el mundo se entera en minutos y no en dos días. Este paso se olvida siempre y es el que más caídas provoca.
• 2. Inventario. Archivos, base de datos, tareas programadas, certificados, cuentas de correo, variables de entorno y las claves de cualquier servicio externo. Lo que no está en la lista es lo que se te olvida.
• 3. Monta la web en el servidor nuevo. Sin tocar el DNS todavía. Copia archivos y base de datos, instala lo que haga falta y déjalo listo.
• 4. Pruébala antes de apuntar nada. Editando tu fichero hosts local puedes ver el servidor nuevo con tu dominio real mientras el resto del mundo sigue viendo el viejo. Aquí se detecta el 90% de los problemas, sin riesgo.
• 5. Congela los cambios. Avisa de que nadie publique ni haga pedidos durante la ventana. Si es una tienda, hazlo de madrugada.
• 6. Sincroniza otra vez lo que cambia. Base de datos y subidas recientes, justo antes de conmutar.
• 7. Cambia el DNS. Con el TTL bajo, en minutos está propagado.
• 8. Emite el SSL en el nuevo. En cuanto el dominio apunte al servidor nuevo.
• 9. No apagues el viejo. Déjalo una o dos semanas. Es tu marcha atrás.
• 10. Sube el TTL otra vez. Cuando esté todo estable.

Si tu dominio también lleva el correo, presta atención aquí, porque es donde se pierden mensajes de verdad:

El correo no viaja con la web. Son registros DNS distintos: la web usa el registro A y el correo usa los MX, más el SPF, el DKIM y el DMARC. Si al migrar copias la zona DNS a medias o dejas que el proveedor nuevo "genere una zona por defecto", te lleva los MX a su propio servidor y los correos empiezan a rebotar sin que nadie se dé cuenta hasta que un cliente llama.

Y si el correo está alojado en el mismo servidor que la web, esa migración es un proyecto aparte: hay que mover los buzones con su contenido, no solo apuntar los registros. Merece la pena aprovechar para separarlos.

La web carga, todo parece bien, y a los tres días descubres alguna de estas:

• Las tareas programadas. Los cron no se copian con los archivos. El aviso de cada noche, la copia de seguridad, el informe semanal: si no los recreas, dejan de existir en silencio.
• Permisos de archivos. La web funciona pero no se pueden subir imágenes, o al revés: los permisos quedan demasiado abiertos y eso es un agujero de seguridad.
• Versión distinta de PHP o Node. Todo va bien hasta que se usa la parte del código que dependía de la versión anterior.
• Rutas absolutas. Configuraciones que apuntan a carpetas del servidor viejo.
• Las copias de seguridad. Estaban configuradas en el viejo. En el nuevo, hasta que las montes, no hay ninguna. Es el fallo más peligroso porque no se nota hasta que necesitas restaurar.
• Redirecciones y HTTPS. Si el servidor nuevo no fuerza HTTPS o pierde las redirecciones antiguas, aparecen errores 404 y ahí sí se resiente el posicionamiento.
• Las IP en listas blancas. Pasarelas de pago, APIs o servicios externos que solo aceptan la IP del servidor viejo.

Sobre el SEO: una migración bien hecha no te hace perder posiciones. Lo que las hace perder son los 404 masivos, que la web tarde mucho más en cargar o que se quede caída días. Si conservas las URL, mantienes las redirecciones y no hay caída larga, Google ni se inmuta. Si tu web ya venía con problemas de visibilidad, eso es otro asunto: está en mi web no aparece en Google.

Si lo que mueves es un WordPress, el detalle específico está en migrar WordPress. Y si aprovechas para cambiar de servidor porque el actual va lento, mira antes por qué va lento: cambiar de servidor no arregla una web mal optimizada.