Cómo migrar tu hosting sin que tu web se caiga

Migrar el hosting es una de esas tareas que dan miedo, sobre todo cuando la web ya tiene tráfico, formularios funcionando y clientes que entran a cualquier hora. La pregunta que me hacen siempre es la misma: ¿se va a caer la web durante la mudanza? La respuesta corta es que no tiene por qué caerse, siempre y cuando sigamos un orden claro y no nos saltemos pasos por apuro. He hecho varias migraciones para clientes de Lima y de provincia, y aprendí que la diferencia entre una mudanza limpia y un desastre está en la preparación previa, no en el día mismo del cambio.

En esta guía te voy a contar cómo migrar tu hosting sin downtime real, qué herramientas uso, qué errores he visto repetirse y cuál es el plan B cuando algo se sale del libreto. No es una receta mágica, pero sí un procedimiento que reduce el riesgo a niveles muy manejables.

Por qué la mayoría de migraciones se complican

El problema casi nunca es técnico en el sentido estricto. Es de planificación. La gente decide migrar un viernes a las cinco de la tarde, no avisa al equipo, no tiene copias completas, asume que el panel nuevo va a comportarse igual que el anterior y descubre a la mala que la versión de PHP es distinta o que el módulo de pasarela de pago necesita una IP específica.

Otra causa frecuente es confundir migración con cambio de DNS. Mucha gente cree que apuntar el dominio al nuevo servidor es la migración. No. Apuntar el dominio es el último paso de un proceso que empieza varios días antes. Si haces el cambio de DNS sin haber probado nada en el destino, lo que vas a tener es una web rota durante horas, no una web migrada.

Preparación previa: el trabajo que evita el desastre

Antes de tocar nada, hago un inventario completo de lo que tiene la web actual. Anoto la versión de PHP que está corriendo, la versión de MySQL o MariaDB, los módulos activos, las tareas programadas en cron, las cuentas de correo, los certificados SSL instalados, los redireccionamientos en .htaccess y cualquier configuración especial. Este inventario es la base de todo. Si no lo tienes, vas a chocar contra detalles tontos a media migración.

Después reviso que el hosting de destino soporte todo lo que la web necesita. Si la web corre en PHP 8.1 y el nuevo plan solo ofrece hasta PHP 7.4, ya tengo un problema. Si uso una base de datos con caracteres especiales y el nuevo servidor no tiene el mismo collation, los textos se pueden romper. Mejor descubrir esto antes que en plena mudanza.

Bajar el TTL de los DNS varios días antes

Este paso es crucial y casi nadie lo hace. El TTL es el tiempo que los servidores DNS del mundo guardan en caché tus registros. Si tu TTL está en 86400 segundos, o sea 24 horas, cuando cambies el DNS hacia el nuevo servidor algunos visitantes seguirán llegando al servidor viejo durante un día completo. Eso sí es downtime real para quienes caen en esa franja.

Lo que hago es bajar el TTL a 300 segundos, o sea cinco minutos, al menos 48 horas antes del cambio. Así, el día de la migración, la propagación se completa en minutos y no en horas. Una vez terminada la migración y verificado que todo funciona, vuelvo a subir el TTL a un valor normal para no saturar las consultas.

Si tu proveedor de DNS es Cloudflare, este paso es aún más fácil porque ellos controlan la caché y el cambio es prácticamente inmediato. Pero igual conviene bajarlo por si acaso algún resolver intermedio mantiene valores antiguos.

Clonar la web en el destino

Una vez que tengo el inventario y el TTL bajo, paso a clonar la web en el nuevo hosting. Hay dos caminos: hacerlo manualmente o usar un plugin de migración si es una web hecha con WordPress, Joomla u otro CMS común. Para sitios pequeños suelo usar herramientas como All-in-One WP Migration o Duplicator. Para sitios más grandes prefiero hacerlo a mano porque tengo más control.

El proceso manual implica tres cosas: copiar todos los archivos vía SFTP o rsync, exportar la base de datos del origen e importarla en el destino, y ajustar los archivos de configuración para que apunten a la nueva base de datos. En WordPress eso significa editar wp-config.php. En otros sistemas son archivos equivalentes.

Aquí hay un detalle importante: si la web tiene plugins de caché activos, conviene desactivarlos antes de exportar. La caché vieja puede generar errores raros en el destino porque guarda rutas absolutas del servidor anterior. Mejor empezar con caché limpia.

Probar en el destino sin tocar el dominio

Una vez clonada la web en el nuevo hosting, el siguiente paso es probarla a fondo sin haber cambiado todavía el DNS. ¿Cómo se hace? Editando el archivo hosts de tu computadora para forzar que tu navegador apunte al nuevo servidor solo desde tu máquina, mientras el resto del mundo sigue viendo el viejo.

En Windows el archivo hosts está en C:\Windows\System32\drivers\etc\hosts. En Mac y Linux está en /etc/hosts. Le agregas una línea con la IP del nuevo servidor y el dominio. Cuando abres tu navegador, tu equipo va al nuevo servidor pero los visitantes normales siguen llegando al viejo. Esta técnica me ha salvado en cada migración que he hecho.

Con la web cargando desde el destino, reviso todo: páginas principales, formularios de contacto, pasarela de pago, carrito si es ecommerce, panel de administración, envío de correo desde formularios, carga de imágenes. Si algo falla, lo arreglo en el destino mientras la web pública sigue funcionando intacta en el origen.

El día del cambio: ajustar los DNS

Cuando la web del destino está probada y funcionando, llega el momento de cambiar los DNS. Esto se hace en el panel del registrador donde compraste el dominio, o en Cloudflare si lo manejas desde ahí. Cambias el registro A para que apunte a la IP del nuevo servidor, y si tienes AAAA también lo actualizas.

Como bajaste el TTL días antes, la propagación va a ser rápida. En cuestión de minutos la mayoría de visitantes ya estarán llegando al nuevo servidor. Pero ojo: durante esa ventana de transición, algunos seguirán llegando al viejo. Por eso es importante mantener el servidor anterior activo durante al menos 48 a 72 horas después del cambio. Si alguien hace una compra o llena un formulario en el viejo, los datos quedan ahí.

Una práctica que recomiendo: sincronizar la base de datos del viejo al nuevo durante esta ventana, o al menos revisarla manualmente al final para no perder pedidos ni mensajes que cayeron en el servidor antiguo durante la transición.

Verificar la propagación

Para confirmar que el cambio se está propagando, uso dnschecker.org. Esta herramienta te muestra cómo se ve tu dominio desde servidores DNS de todo el mundo. Vas viendo cómo de a pocos van apareciendo verdes los nodos que ya ven la nueva IP. Cuando todos los principales están actualizados, sabes que la propagación está completa.

También uso comandos simples desde la terminal. En Windows funciona nslookup midominio.com. En Mac y Linux uso dig midominio.com. Estos comandos te dicen qué IP está respondiendo en ese momento desde tu red. Si ves la IP nueva, ya estás del lado correcto.

No confíes solo en lo que ves desde tu propia computadora. Pide a colegas de otras ciudades o usa servicios de monitoreo externos para confirmar que la web responde bien desde múltiples puntos. La experiencia de un usuario en Cusco puede ser distinta a la de uno en Lima durante la propagación.

Migración del correo: capítulo aparte

Si tu dominio maneja correo en el mismo hosting, este es el punto donde más errores he visto. El correo no se migra cambiando un DNS y listo. Hay que mover los buzones, configurar los registros MX en el nuevo proveedor, mantener ambos servidores recibiendo durante la transición y avisar a los usuarios para que reconfiguren sus clientes de correo si es necesario.

Lo que hago es crear primero todas las cuentas en el nuevo hosting con las mismas direcciones. Después uso herramientas como imapsync para copiar los mensajes existentes del viejo al nuevo. Una vez que las cuentas están listas y sincronizadas, cambio los registros MX. Durante 24 a 48 horas, ambos servidores reciben correo porque la propagación toma su tiempo. Vuelvo a sincronizar al final para asegurarme de no perder mensajes.

Si usas un servicio externo como Google Workspace o Microsoft 365 para el correo, este problema desaparece porque los MX no cambian con la migración del hosting. Es una de las razones por las que recomiendo siempre separar el correo del hosting principal.

Plan B: qué hacer si algo se rompe

Por más cuidado que pongas, siempre puede pasar algo inesperado. Por eso antes de cambiar los DNS guardo dos cosas: un backup completo del estado de la web en el origen, y la IP del servidor viejo anotada en un papel. Si después del cambio descubro que algo crítico no funciona en el destino, puedo revertir el DNS al servidor viejo en cuestión de minutos y la web vuelve a estar como antes.

Este plan de reversión es lo que me deja dormir tranquilo. No tienes que arreglar el problema en plena urgencia. Vuelves al estado anterior, investigas con calma qué pasó y haces un segundo intento con el problema ya resuelto. Esto solo funciona si mantuviste el hosting viejo activo, por eso insisto tanto en no cancelarlo el mismo día.

También conviene tener a mano el contacto de soporte técnico de ambos hostings. He tenido casos donde el problema era un módulo PHP que el nuevo proveedor activó en cinco minutos cuando se lo pedí. Si no hubiera tenido ese canal abierto, habría perdido horas.

Monitoreo post-migración

Los primeros días después de la migración son críticos. Uso servicios como UptimeRobot o StatusCake para monitorear que la web responda cada minuto desde varias regiones. Si algo se cae, recibo una alerta al correo. Revisa también Google Search Console por si aparecen errores de rastreo nuevos, y mide la velocidad con PageSpeed Insights o GTmetrix.

Errores comunes que se repiten

El primero: no probar la web en el destino antes de cambiar el DNS. Esto causa más caídas que cualquier otro problema. El segundo: olvidar las tareas programadas. Si tienes crons que envían correos, generan reportes o limpian caché, hay que copiarlos al nuevo servidor. Si no, dejan de funcionar y nadie se da cuenta hasta que un cliente reclama.

El tercer error es no actualizar las rutas absolutas. Algunas configuraciones guardan rutas completas del servidor anterior. Si el nuevo hosting tiene una estructura distinta de carpetas, esas rutas quedan rotas. Conviene revisar archivos de configuración y reemplazar lo que haga falta.

El cuarto: olvidar el certificado SSL. El nuevo servidor necesita su propio certificado. Si usabas uno gratuito de Let’s Encrypt, hay que instalarlo en el destino antes del cambio de DNS. Si tenías uno pagado, hay que reinstalarlo o emitir uno nuevo. Una web sin HTTPS después de la migración pierde confianza y posicionamiento.

Preguntas frecuentes sobre migración de hosting sin downtime

¿Cuánto tiempo demora migrar un hosting completo?

Depende del tamaño de la web. Un sitio pequeño con pocos gigabytes puede migrarse en una mañana. Un sitio grande con base de datos pesada y miles de archivos puede tomar uno o dos días contando pruebas. La copia en sí suele ser lo más rápido; las pruebas y la propagación son las que extienden el tiempo total.

¿Es necesario contratar a alguien para migrar?

No siempre. Si tu web es sencilla y manejas conceptos básicos de FTP y bases de datos, puedes hacerlo. Si es una web crítica para tu negocio, conviene pagarle a alguien con experiencia para reducir riesgos. El costo de contratar siempre es menor que el costo de tener la web caída durante horas.

¿Puedo migrar sin que mis visitantes se den cuenta?

Sí, esa es justamente la idea de esta guía. Si bajas el TTL, clonas y pruebas antes, mantienes ambos servidores activos durante la transición y monitoreas la propagación, la mayoría de visitantes no notará nada. Algunos pueden caer al servidor viejo durante un rato, pero verán la web igual que siempre.

¿Qué pasa con mi posicionamiento en Google?

Si la migración respeta las URLs, las redirecciones y los tiempos de carga, el impacto en SEO es mínimo. Google entiende los cambios de servidor y ajusta su rastreo. Lo que sí puede afectar es un cambio brusco de velocidad o errores 500 durante el cambio. Por eso conviene monitorear Search Console los primeros días.

¿Tengo que avisar a mis clientes antes de migrar?

Si tienes una tienda activa o un servicio crítico, avisar es una buena práctica aunque la migración sea sin downtime. Un mensaje corto diciendo que va a haber mejoras técnicas en cierta franja horaria genera confianza. Si algo sale mal, los clientes ya están avisados y no toman a mal una incidencia breve.

¿Cómo sé si la migración terminó completamente?

Cuando dnschecker.org te muestra todos los nodos principales con la nueva IP, cuando tu monitoreo no detecta caídas durante 48 horas seguidas, cuando los formularios y procesos críticos funcionan en el destino, y cuando ya no llega tráfico al servidor viejo según sus logs. Recién ahí puedes considerar cerrado el proceso.

¿Puedo cancelar el hosting viejo inmediatamente después de cambiar el DNS?

No lo recomiendo. Mantén el hosting viejo activo al menos una semana después del cambio. Esto te da margen para detectar problemas tardíos, recuperar datos que llegaron al servidor antiguo durante la transición y revertir el DNS si algo grave aparece después.

¿Qué hago si pierdo correos durante la migración?

Si pasó, sincroniza nuevamente con imapsync los buzones del viejo al nuevo. La mayoría de las veces los correos siguen guardados en el servidor antiguo. Si los perdiste de verdad, revisa si tu hosting tiene backups recientes para restaurar las casillas. Por eso es vital no cancelar el servicio anterior demasiado pronto.

¿Migrar hosting cambia mi dirección IP?

Sí. Cada hosting tiene sus propias IPs. Por eso el cambio de DNS es necesario. Si tienes servicios externos que dependen de tu IP, como autenticación de pasarelas de pago o envío de correo desde aplicaciones, hay que actualizar esas configuraciones para que reconozcan la nueva IP.

¿Necesito hacer una migración si solo voy a cambiar de plan dentro del mismo hosting?

Generalmente no. Los cambios de plan dentro del mismo proveedor suelen ser transparentes y los hace el soporte sin que tengas que mover archivos. Solo si cambias de servidor físico, de centro de datos o de tipo de hosting compartido a VPS, ahí sí puede haber una migración real.