Migrar tu web sin perder nada: guía de migración y backup
Cambiar de hosting no tiene por qué romper la web ni el SEO. Un plan de migración y backup paso a paso, con copias que se prueban y una vuelta atrás preparada.
Una migración y backup bien hechos son invisibles. La web sigue respondiendo, los correos llegan y Google apenas nota un cambio. Cuando salen mal, en cambio, se recuerdan durante meses: formularios que no envían, imágenes que desaparecen y posiciones que se caen sin motivo aparente.
La buena noticia es que casi todos los desastres tienen la misma causa. No es la tecnología: es empezar por el paso tres. Se copian los archivos, se cambia el DNS y se confía en que todo encaje. El correo, las redirecciones y la vuelta atrás se dejan para después.
En este artículo tienes el orden correcto, las comprobaciones que casi nadie hace y un plan para volver si algo se tuerce.
Una migración es llevar una web de un sitio a otro. Puede ser de hosting, de dominio, de gestor de contenidos o de las tres cosas a la vez.
Lo que se pierde no suele ser el HTML. Se pierden cosas que no están en la carpeta pública:
- La base de datos. Entradas, usuarios, pedidos, ajustes del tema.
- El correo. Si el DNS cambia y los registros MX no, los mensajes se quedan en el limbo.
- Las redirecciones. Si las URLs cambian y nadie las mapea, los enlaces externos apuntan a un 404.
- Los permisos. Carpetas que el servidor nuevo no puede escribir y formularios que dejan de enviar.
- Las tareas programadas. Copias automáticas, envíos y limpiezas que vivían en el panel antiguo.
Una migración ordenada consiste en inventariar todo eso antes de tocar nada.
El primer día no se migra. Se apunta.
Haz una lista con esto:
- versión del gestor y de los plugins o dependencias;
- tamaño de archivos y de la base de datos;
- direcciones de correo y registros DNS actuales;
- formularios, integraciones y servicios externos;
- URLs que reciben tráfico y enlaces desde otras webs.
Con el inventario hecho, llega la copia. Y aquí va la regla que separa un backup de un adorno: la copia se prueba. Descárgala, restáurala en un entorno de pruebas y comprueba que la web abre, que el panel entra y que un formulario envía.
Si restaurar tarda dos horas y falla a mitad, mejor saberlo un martes por la mañana que un viernes por la noche.
Tres destinos es una buena costumbre: una copia en el servidor, otra fuera de él y una tercera en un sitio distinto del proveedor. Si el hosting desaparece, la copia que vivía en el mismo hosting desaparece con él.
Y revisa la frecuencia. Una web con pedidos diarios necesita una copia diaria y conservar al menos dos semanas. Un blog que publica dos veces al mes puede vivir con una copia semanal.
El SEO no se rompe por cambiar de servidor. Se rompe por cambiar las URLs sin avisar.
Si la estructura se mantiene, el riesgo es bajo. Si cambia, cada URL antigua necesita una redirección 301 a su equivalente nueva. Las que no tengan equivalente deberían llevar a la sección más cercana, no a la portada.
El orden que funciona:
- Monta la web nueva en un entorno de pruebas, bloqueada a los buscadores.
- Prueba las URLs una a una y crea el mapa de redirecciones.
- Cambia el DNS en una franja de poco tráfico y con el TTL bajo.
- Comprueba que las redirecciones responden con un solo salto.
- Envía el sitemap actualizado y revisa los errores en Search Console durante dos semanas.
No hagas coincidir la migración con un rediseño. Si algo se rompe, no sabrás si fue el servidor o el diseño. Primero se migra, se estabiliza y después se cambia la imagen.
Tener copias no es lo mismo que poder recuperar. Muchos backups fallan por detalles tontos:
- el archivo está cifrado y nadie recuerda la contraseña;
- la copia incluye archivos pero no la base de datos;
- la retención es de tres días y el problema se descubre al cuarto;
- el destino es el mismo servidor que se ha caído.
Un plan de backup decente responde a cuatro preguntas:
- Qué se copia: archivos, base de datos, correo y configuración.
- Cada cuánto: según cuánto dato puedes permitirte perder.
- Dónde: fuera del servidor principal, con acceso independiente.
- Cómo se restaura: con un procedimiento escrito y probado.
La última es la que casi nunca existe. Si no hay un documento con los pasos y alguien que los haya ejecutado, la copia es una hipótesis.
Un backup también es un objetivo para un ataque. Si el servidor se compromete y la copia está montada con las mismas credenciales, el atacante puede borrar las dos.
Por eso conviene separar accesos y usar cuentas distintas. Sobre esto, seguridad web para pymes cubre los puntos que no pueden esperar al lunes.
Antes de cambiar el DNS, decide qué harás si a las dos horas algo no funciona. No improvises con el sitio caído. Un plan de migración y backup se juzga por lo que ocurre cuando algo falla, no por lo que promete el proveedor.
El plan mínimo:
- conserva el hosting antiguo activo y pagado durante al menos una semana;
- apunta los DNS anteriores en un documento;
- comprueba que puedes volver a apuntar el dominio;
- deja escrito quién decide la vuelta atrás y en qué plazo.
Volver atrás no es un fracaso. Es lo que permite migrar con calma en lugar de mirar el reloj.
Puedes hacerlo tú si la web es pequeña, no tiene tienda y el correo está separado. Es un fin de semana de trabajo con una lista delante.
Conviene delegarlo cuando hay pedidos, usuarios registrados, integraciones o un equipo que depende del correo. Ahí el coste de un error supera al de un profesional.
También cuando el hosting actual no te da acceso completo o el proveedor anterior no colabora. Una migración y backup de tu web con copia verificada, redirecciones y periodo de marcha atrás cuesta menos que perder un fin de semana de ventas.
Si el problema es que la web va lenta y crees que el hosting es la causa, revisa antes cuándo el hosting es el problema real. Cambiar de servidor una web pesada solo esconde el problema.
Una web corporativa pequeña puede migrarse en una tarde, más el tiempo de propagación del DNS. Una tienda con pedidos y correo propio suele necesitar un fin de semana y varios días de revisión.
Si las URLs se mantienen o se redirigen bien, el impacto debería ser mínimo y temporal. El riesgo aparece cuando se cambian rutas sin 301 o se bloquea el sitio nuevo por error.
Sí. Se prepara el entorno nuevo, se prueba y solo al final se cambia el DNS. El corte real dura lo que tarda en propagarse el dominio, entre minutos y unas horas.
Depende de cuánto dato puedes perder. Para una web con pedidos, a diario. Para un blog, una vez a la semana puede bastar. Lo importante es probar la restauración y guardar copias fuera del servidor.
El correo no se migra solo. Hay que conservar los registros MX y la configuración de autenticación, o mover los buzones con tiempo. Si el correo está separado del hosting, este paso es mucho más sencillo.