Cómo migrar sitios web de forma segura
Publicado el 21 de junio de 2026
Una migración segura de un sitio web empieza antes de mover cualquier archivo. Si quieres saber cómo migrar sitios web de forma segura, la primera tarea no es copiar datos: es reducir las incógnitas. Revisamos el stack actual, congelamos los cambios innecesarios, confirmamos que las copias de seguridad realmente se puedan restaurar y creamos una ruta de reversión antes de tocar el DNS. Esa es la parte que muchos equipos se saltan, y más tarde los registros cuentan la misma historia.
Las migraciones fallan por motivos aburridos. Un cron job olvidado sigue escribiendo en la base de datos antigua. El DNS se cambia antes de que el SSL esté listo. Las reglas de redirección se copian a medias. La caché hace que el sitio nuevo parezca estar bien para una persona y roto para todos los demás. Nada de esto es dramático, pero sí es caro. Una migración segura es, sobre todo, una secuenciación disciplinada.
Cómo migrar sitios web de forma segura sin sorpresas de tiempo de inactividad
Las migraciones más limpias empiezan con un inventario. Necesitas saber exactamente qué se va a mover, qué puede cambiar durante el traslado y qué dependencias están fuera del servidor. Eso incluye archivos del sitio web, bases de datos, almacenamiento de medios, certificados SSL, zonas DNS, tareas programadas, enrutamiento de correo electrónico, integraciones de API, callbacks de pago y reglas de firewall. Si el sitio usa una CDN, almacenamiento externo de imágenes, caché de objetos o búsqueda de terceros, inclúyelos también.
Aquí es donde los equipos encuentran las pequeñas trampas. Una tienda WooCommerce podría depender de un webhook de pago que apunta a la IP antigua. Una aplicación SaaS puede tener queue workers en una segunda máquina. Un sitio de marketing puede ser simple, pero el formulario de contacto envía a través de un servicio SMTP restringido por el nombre de host del servidor. Las migraciones seguras rara vez tratan sobre la página de inicio. Tratan sobre los bordes.
Antes de mover nada, decide qué tipo de migración vas a hacer. Un traslado equivalente de un VPS a otro tiene un nivel de riesgo. Pasar de hosting compartido a VPS gestionado, cambiar de panel de control, actualizar PHP y cambiar el servidor web de Apache a Nginx al mismo tiempo es otra historia. Puedes hacer varios cambios a la vez, pero cada variable adicional hace que la resolución de problemas sea más lenta. Si es posible, separa los cambios de infraestructura de los cambios de aplicación.
Empieza con copias de seguridad que ya hayas probado
Todos los proveedores dicen que existen copias de seguridad. Eso está bien, pero una copia de seguridad solo es útil si se restaura limpiamente y con la rapidez suficiente para tu objetivo de recuperación. Crea una copia de seguridad reciente de archivos y bases de datos inmediatamente antes de la migración. Mantén también una copia externa al entorno de origen, para no depender de que una sola plataforma tenga un buen día.
Si el sitio es importante para los ingresos, realiza una restauración de prueba en un entorno de staging. Abre el sitio restaurado, verifica la conectividad de la base de datos, comprueba los permisos de archivos y asegúrate de que los medios carguen. Si no puedes probar toda la aplicación, al menos confirma que el archivo de la copia de seguridad está completo y que el database dump es legible. No es un trabajo glamuroso, pero tampoco lo es explicar a contabilidad por qué los pedidos de anoche desaparecieron en el bosque.
Congela los cambios durante la ventana de migración
Las ediciones de contenido, las instalaciones de plugins y los despliegues de código durante la migración crean problemas de split-brain. Un sistema se actualiza, el otro no, y ahora nadie está seguro de qué versión es la real. Establece una congelación breve de cambios. Para sitios con mucho contenido o transaccionales, usa el modo de mantenimiento o pon las partes críticas en estado de solo lectura durante la sincronización final.
Para comercio electrónico, reservas o contenido generado por usuarios, planifica una sincronización delta. Copia la mayor parte de los archivos y datos por adelantado, y luego haz una sincronización final durante la ventana de cambio para capturar los cambios de última hora. Esto mantiene bajo el tiempo de inactividad sin arriesgar la deriva de datos.
Construye el entorno de destino antes del cambio
Un error común es tratar el servidor de destino como una caja vacía que puede configurarse más tarde. La migración segura funciona al revés. El entorno de destino debe estar listo antes del cambio: SO parcheado, stack web instalado, versión de PHP confirmada, base de datos ajustada, SSL preparado, copias de seguridad programadas y monitorización habilitada.
Primero iguala los requisitos de la aplicación y luego mejora con cuidado. Si el sitio antiguo funciona con PHP 7.4 y la aplicación no está certificada para PHP 8.2, el día de la migración no es el momento para la valentía. Puedes modernizar después de confirmar la estabilidad. Primero calma, después optimización.
Los permisos y la propiedad merecen atención adicional. Muchos incidentes de “el sitio migró, pero las subidas fallan” son simplemente propiedad de usuario/grupo incorrecta o rutas escribibles ausentes. Revisa también los cron jobs, los queue workers y las tareas programadas. Un sitio puede cargar bien mientras un procesamiento importante en segundo plano se detuvo silenciosamente hace una hora.
Prueba usando un hosts file o una URL temporal
No apuntes el DNS en vivo hasta que el sitio se haya comprobado en el servidor nuevo. Usa una anulación del hosts file o un dominio temporal de vista previa para probar la aplicación de forma privada. Navega por páginas clave, envía formularios, inicia sesión como administrador, realiza un pedido de prueba si corresponde y verifica el envío de correo electrónico. Comprueba imágenes, búsqueda, API, acciones de administración y cualquier cosa vinculada a sesiones o caché.
Mira más allá de las comprobaciones visuales. Revisa registros de errores, registros del servidor web, estado de PHP-FPM, consultas lentas de base de datos y uso de disco. Confirma que las redirecciones funcionen como se espera. Asegúrate de que las URL canónicas, las reglas de robots y las variables de entorno sean correctas. Es sorprendentemente fácil migrar un sitio de producción con una cabecera noindex de staging todavía adjunta. Los motores de búsqueda son obedientes en los peores momentos posibles.
DNS, TTL y planificación del cambio
Si estás aprendiendo cómo migrar sitios web de forma segura, el DNS es donde la preparación da sus frutos. Reduce el TTL en los registros DNS relevantes bastante antes de la ventana de migración, idealmente con 24 a 48 horas de antelación. Esto ayuda a que los resolvers se actualicen más rápido cuando cambias el sitio al servidor nuevo. No garantiza una propagación global instantánea, pero reduce el tiempo durante el cual los usuarios pueden llegar a la ubicación antigua.
En el momento del cambio, actualiza solo lo necesario. Normalmente eso significa el registro A, quizá AAAA y, a veces, registros relacionados con el correo si el correo electrónico también se está moviendo. Ten cuidado de no mezclar la migración del sitio web con la migración del correo electrónico a menos que haya una razón clara. Combinarlas aumenta el radio de impacto. La migración más bonita suele ser la que cambió menos cosas.
Mantén el servidor antiguo activo durante un periodo seguro de solapamiento. Incluso después del cambio de DNS, algunos usuarios y bots seguirán llegando al host antiguo durante un tiempo. Durante este periodo, monitoriza los registros de acceso en ambos sistemas. Si el servidor antiguo todavía recibe tráfico significativo, mantenlo disponible y, si es posible, dirige cuidadosamente la actividad de escritura para no perder datos.
Vigila los problemas de caché y SSL
Las cachés de CDN, las cachés de aplicación y la caché local del navegador pueden ocultar problemas después de la migración. Purga donde sea necesario. Si se usa una caché de página completa, límpiala después de la sincronización final y después del cambio de DNS. Confirma que el origen de la CDN esté actualizado si existe uno.
El SSL debe estar listo antes del cambio, no después. Instala los certificados en el entorno nuevo, verifica la cadena completa y prueba el comportamiento de HTTP a HTTPS. Pueden aparecer advertencias de contenido mixto si las URL de recursos codificadas de forma rígida todavía apuntan al dominio o protocolo antiguo. Son detalles pequeños, pero los usuarios notan el icono del candado más rápido de lo que notan tu cuidadosa planificación.
Redirecciones, SEO e integridad de la aplicación
Si el dominio sigue siendo el mismo, el riesgo de SEO es menor, pero las comprobaciones técnicas siguen importando. Asegúrate de que las redirecciones de HTTP a HTTPS, de www a sin www o al revés, y cualquier mapeo de rutas antiguas se comporten exactamente como se espera. Si el dominio cambia, usa redirecciones 301 de forma integral y actualiza etiquetas canónicas, sitemaps y referencias internas.
No lances con cadenas de redirección si puedes evitarlas. Ralentizan las cosas y crean un lío de indexación. Comprueba también las páginas de error personalizadas, robots.txt, la generación del sitemap XML y los datos estructurados si el sitio depende de ellos. La migración no es solo “el sitio carga”. Es “el sitio se comporta correctamente en condiciones normales y límite”.
Para aplicaciones dinámicas, prueba la autenticación, las sesiones y los permisos con roles de usuario reales. La administración puede funcionar mientras el inicio de sesión de clientes falla por el alcance de las cookies, el almacenamiento de sesiones o las cabeceras de proxy. Esto es especialmente común detrás de balanceadores de carga o proxies inversos.
El plan de reversión forma parte de la migración
Una migración solo es segura si la reversión es posible. Define por adelantado las condiciones de reversión. Por ejemplo: errores 5xx sostenidos, fallo en el checkout, inicio de sesión roto, regresión grave de rendimiento o discrepancia de datos. Define también quién toma la decisión de revertir y cuánto dura la ventana de observación después del cambio.
La reversión debe ser lo bastante sencilla como para ejecutarse bajo estrés. Eso suele significar mantener intacto el entorno antiguo, preservar el estado de la base de datos antigua si es posible y revertir rápidamente el DNS o el enrutamiento de tráfico. Si hubo escrituras en el entorno nuevo, necesitas una política para la reconciliación de datos. Por eso los sitios web transaccionales requieren cuidado adicional durante el cambio final.
Monitoriza intensamente durante las primeras 24 horas
Después del cambio, vigila el uptime, el tiempo de respuesta, CPU, memoria, E/S de disco, carga de base de datos, validez de SSL, profundidad de cola y trabajos de copia de seguridad. Vigila también las señales visibles para el usuario: flujo de pedidos, formularios de contacto, éxito de inicio de sesión e informes de errores. Una migración puede verse bien en el minuto diez y fallar en la hora tres cuando se activan las tareas programadas o expira la caché.
Aquí es donde el soporte gestionado se gana su lugar. Una buena monitorización detecta picos de recursos, servicios fallidos y problemas de certificados antes de que los clientes se conviertan en tu sistema de alertas. Para equipos sin mucha profundidad operativa interna, esa capa operativa tranquila importa más que otra casilla en un plan de hosting.
Una regla práctica para migraciones más seguras
No cambies todo solo porque por fin tienes la oportunidad. Primero mueve, luego estabiliza y después mejora. Ese orden ahorra tiempo, aunque sobre el papel parezca más lento. Si necesitas ayuda sobre cómo migrar sitios web de forma segura, el socio de hosting adecuado debería poder ayudarte no solo con el servidor en sí, sino también con copias de seguridad, monitorización, planificación de reversión y esos pequeños casos límite incómodos que aparecen solo después de medianoche.
Una buena migración se siente casi sin incidentes. Ese es el objetivo. Registros tranquilos, tráfico estable, formularios funcionando, ningún desastre misterioso de cron y un equipo que puede dormir después del cambio de DNS. En kodu.cloud, ese suele ser el estándar al que aspiramos: nada llamativo, simplemente bajo control.
Andres Saar Ingeniero de atención al cliente