Migración de sitio sin tiempo de inactividad: cambiar de servidor sin cortar el acceso a los visitantes
Una migración de sitio sin tiempo de inactividad es el método que permite trasladar un sitio a un nuevo servidor sin mostrar errores a los visitantes, sin romper los formularios ni perder datos en el camino. El principio es simple en teoría: preparar, sincronizar, probar, cambiar el DNS y luego monitorear. En la práctica, es principalmente una cuestión de disciplina y orden en las operaciones.
Si quieres hacerlo correctamente, el objetivo no es solo “copiar un sitio”. Hay que reproducir el entorno, reducir el impacto de la propagación del DNS, gestionar las escrituras durante la transición y tener un plan de reversión listo para usar. Eso es exactamente lo que esta guía te hace ejecutar, paso a paso.
En resumen
🔧 Reduce el TTL del DNS 48 horas antes del cambio para acelerar la propagación y limitar la espera.
🧩 Mantén ambos servidores activos el tiempo necesario para sincronizar los archivos, la base y los parámetros críticos.
🧪 Prueba el nuevo servidor a través del archivo hosts antes de tocar el DNS público.
🚨 Congela las escrituras en el momento adecuado si el sitio recibe pedidos, inscripciones o modificaciones sensibles.
¿Qué resultado buscar al final de una migración de sitio sin tiempo de inactividad?
El resultado esperado es un sitio que responde desde el nuevo servidor sin interrupción visible para el usuario, con los mismos contenidos, los certificados SSL correctos, redirecciones coherentes y una base de datos actualizada. En otras palabras, el cambio debe ser invisible, salvo para ti que controlas la estabilidad, los registros y la propagación del DNS.
¿Cómo migrar un sitio sin tiempo de inactividad en la práctica?
La secuencia correcta consta de seis movimientos. Primero, haces un inventario y copias todo. Luego, preparas el nuevo servidor de manera idéntica. Después pruebas en local o en preproducción. Luego sincronizas una última vez los datos, cambias el DNS en el momento adecuado y supervisas el sitio hasta la validación completa.
- Inventariar los archivos, la base, el SSL, los cron, los correos electrónicos y las integraciones.
- Respaldar antes de cualquier copia, con una versión local y una copia externa.
- Preparar el nuevo servidor de manera idéntica, o con las diferencias documentadas.
- Probar el sitio antes de la puesta en producción pública.
- Sincronizar los últimos datos y cambiar el DNS.
- Supervisar después del corte lógico, incluso si el sitio no se corta visiblemente.
Preparar la migración con anticipación
La preparación representa la mitad del resultado. Si saltas este paso, terminarás corrigiendo errores de versión, permisos rotos o datos faltantes en el peor momento. El buen hábito es listar todo, respaldar todo y documentar todo antes de abrir cualquier terminal.
Hacer el inventario completo del sitio
Comienza por identificar los componentes realmente usados por el sitio. Esto evita el clásico error: “olvidamos la caché, el cron o el certificado”. Anota todo en un archivo de migración y luego compáralo con el servidor destino. Este documento también servirá como red de seguridad si necesitas revertir.
| Elemento a inventariar | Lo que hay que registrar | Por qué es crítico |
|---|---|---|
| Archivos del sitio | Código, medios, temas, plugins, recursos | Evita archivos faltantes o versiones incoherentes |
| Base de datos | Nombre, usuario, codificación, estructura | Garantiza una importación limpia y datos intactos |
| Certificado SSL | Tipo, nombre de dominio, fecha de expiración | Evita alertas de seguridad tras el cambio |
| Cron y tareas programadas | Frecuencia, scripts ejecutados, dependencias | Preserva envíos, sincronizaciones y procesos automáticos |
| Emails y servicios relacionados | Cuentas, relés SMTP, webhooks, API | Reduce las interrupciones funcionales tras la migración |
Reducir los riesgos antes de la transferencia
Antes de copiar cualquier cosa, haga una copia de seguridad completa del sitio web. Guarde los archivos, las bases de datos, las cuentas de correo electrónico, los certificados SSL y las configuraciones personalizadas. La doble red de seguridad sigue siendo simple: una copia local y una copia en la nube. Si una falla, la otra le salva.
- Valide el espacio en disco disponible en el servidor destino.
- Verifique las versiones de software requeridas por el sitio.
- Reduzca el TTL DNS a 300 segundos aproximadamente 48 horas antes del cambio.
- Informe a los equipos si el sitio gestiona pedidos, inscripciones o contenidos sensibles.
El verdadero riesgo no es la copia del sitio, sino el momento en que el servidor antiguo y el nuevo dejan de estar sincronizados.
Reproducir el entorno en el nuevo servidor
El objetivo no es crear un servidor “casi igual”. Hay que ajustarse al entorno original en los puntos que importan: motor PHP u otro runtime, versión del servidor web, base de datos, extensiones, permisos, rutas y variables de entorno. Cuanto más precisa sea la correspondencia, menos incompatibilidades invisibles se generan en la primera prueba.
Instalar la misma pila técnica
Compare el sistema, la versión del servidor web, la versión de PHP o del runtime usado, así como los módulos necesarios. Esta comparación es aún más importante si el sitio depende de extensiones específicas, reglas de reescritura o una caché de aplicación particular. En un WordPress o una aplicación a medida, una pequeña diferencia de versión puede desencadenar grandes efectos secundarios.
Restaurar los datos
Copie los archivos del sitio, importe la base de datos y luego controle los permisos. Una vez restaurado el contenido, verifique las rutas, las URL internas, las variables de entorno y los parámetros de conexión. Si el sitio usa caché, desactívelo temporalmente durante las pruebas para evitar falsos positivos.
Si el nuevo servidor no reproduce idénticamente al antiguo en los puntos críticos, la migración sin tiempo de inactividad se convierte en una lotería.
¿Qué controles realizar antes de tocar el DNS?
Antes de modificar cualquier entrada pública, debe validar el sitio en el nuevo servidor en un entorno aislado. La idea es verificar el renderizado, los formularios, las conexiones y las áreas con lógica de negocio fuerte, sin exponer el nuevo servidor a los visitantes. Ahí es donde el archivo hosts se convierte en su mejor aliado.
Probar mediante el archivo hosts
Redirija su equipo a la nueva dirección del servidor con el archivo hosts, luego abra las páginas clave como si el DNS ya estuviera cambiado. Compare la página de inicio, las páginas profundas, la conexión de usuario, el carrito, los formularios y las páginas de confirmación. En cuanto aparezca una discrepancia, corríjala antes de la puesta en línea pública.
- Verifique los enlaces internos y las redirecciones.
- Pruebe la generación de páginas dinámicas.
- Valide los formularios y los correos electrónicos transaccionales.
- Controle el certificado SSL y las advertencias del navegador.
Realizar el cambio sin interrupciones
El cambio de DNS debe realizarse cuando la propagación ha sido preparada y cuando el tráfico es lo más bajo posible. En un sitio editorial, esto puede hacerse sin congelar estrictamente las escrituras. En una tienda o una aplicación, a menudo es necesario bloquear temporalmente las acciones que modifican los datos para evitar incoherencias entre el servidor antiguo y el nuevo.
Congelar las escrituras si el contexto lo exige
Active un modo de mantenimiento o bloquee las acciones críticas en el momento previsto: pedidos, inscripciones, modificaciones de perfil, publicaciones o pagos. Luego, realice una última sincronización de los archivos y de la base de datos. Esta última pasada es corta, pero marca toda la diferencia entre una migración limpia y un sitio con datos divergentes.
Modificar los DNS en el momento adecuado
Actualice la dirección del dominio hacia el nuevo servidor y luego supervise la propagación. El servidor antiguo debe permanecer activo durante la transición, ya que algunos visitantes seguirán accediendo a él mientras los DNS no se hayan propagado completamente. Esto es normal, y precisamente por eso se prepara el TTL de antemano.
Si hay dudas sobre los datos, se suspende el cambio. Forzar la puesta en producción suele costar más que un aplazamiento de 30 minutos.
¿Cómo verificar que la migración realmente ha terminado?
Una migración no termina en el momento en que el DNS apunta al nuevo servidor. Termina cuando los controles técnicos y de negocio están todos en verde. Por lo tanto, hay que verificar el sitio como lo harían sus visitantes, pero también como lo haría su servidor de producción: registros, certificados, caché, formularios, conexiones y rendimiento.
Controles técnicos inmediatos
Pruebe la página de inicio, la navegación, los formularios, el certificado SSL, las redirecciones y las páginas dinámicas. Abra los registros del servidor y los logs de la aplicación para detectar errores silenciosos. Si existe un CDN o una caché intermedia, límpiela y verifique que los contenidos servidos correspondan a la versión esperada.
Controles de negocio
En un comercio electrónico, verifique los pedidos, los pagos, los correos electrónicos transaccionales y las cuentas de clientes. En un sitio editorial, controle la publicación, la búsqueda interna y los formularios de contacto. En una aplicación, pruebe la sesión, los permisos y los flujos críticos. En resumen, no se conforme con que “la página de inicio se muestre”.
¿Qué hacer si la migración sale mal?
El plan de reversión debe estar listo antes del cambio, no después. Si observa una corrupción de datos, un error crítico, un rendimiento anormal o una incompatibilidad bloqueante, debe poder volver al servidor antiguo rápidamente. El rollback no es un fracaso: es un seguro.
Activar el rollback en el momento adecuado
Retroceda tan pronto como el problema afecte la coherencia de los datos, la disponibilidad de funciones clave o la estabilidad general del sitio. Tenga en cuenta que un sitio parcialmente roto cuesta más que una puesta en espera de unos minutos. La migración sin downtime no permite improvisaciones en producción.
Volver atrás de forma limpia
Reactive el servidor antiguo, restaure si es necesario los últimos ajustes DNS y reinyecte los datos que se hayan ingresado durante la ventana de transición. Luego, documente con precisión lo que falló. Este registro le evitará repetir el mismo escenario idéntico en la próxima migración.
Casos particulares a tratar
Algunos sitios requieren más delicadeza que otros. Una migración sin downtime en una tienda en línea o una aplicación con muchas escrituras no se maneja como un simple blog. Entonces hay que supervisar la sincronización final, el bloqueo de las escrituras críticas y los servicios externos conectados al sitio.
| Tipo de sitio | Punto principal de vigilancia | Acción a prever |
|---|---|---|
| Sitio vitrina | Páginas estáticas y formulario de contacto | Probar el renderizado, el SSL y las redirecciones |
| Blog | Base de datos y medios | Controlar las importaciones, la caché y los enlaces permanentes |
| Tienda en línea | Pedidos, stock, pagos | Congelar las escrituras críticas y sincronizar en el último momento |
| Aplicación web | Sesiones, permisos, API | Verificar las rutas, los identificadores y las integraciones |
Sitio de comercio electrónico o aplicación con muchas escrituras
En estos sistemas, la menor escritura durante el cambio puede crear una discrepancia entre los dos entornos. El buen reflejo consiste en bloquear las operaciones sensibles, terminar la sincronización final y luego reabrir el acceso solo después de las verificaciones. Es menos glamoroso que una migración “en vivo”, pero mucho más seguro.
Migración con CDN, caché o servicios externos
Si hay un CDN o una caché de aplicación en funcionamiento, es necesario verificar el origen, purgar las capas de caché y controlar los webhooks o integraciones externas. De lo contrario, corres el riesgo de mostrar contenidos obsoletos mientras el servidor ya está correcto. Este desfase es una de las trampas más frustrantes de diagnosticar después.
Errores frecuentes a evitar
La mayoría de las migraciones fallidas no se rompen por un error exótico. Se rompen por un detalle olvidado, una prueba incompleta o un cambio realizado demasiado rápido. Los casos a continuación vuelven constantemente en producción, tanto en sitios vitrinas como en tiendas más sensibles.
- Olvidar reducir el TTL: la propagación DNS se demora y prolonga la superposición entre servidores antiguos y nuevos.
- No verificar la base de datos: la importación pasa, pero algunas tablas o codificaciones causan problemas en la primera visualización.
- Ignorar los permisos: los medios, cachés o exportaciones ya no pueden escribirse correctamente.
- Apagar demasiado pronto el servidor antiguo: algunos visitantes todavía llegan a la IP antigua durante la propagación.
- Probar solo la página de inicio: las páginas profundas, formularios y zonas conectadas a menudo revelan los verdaderos errores.
Optimizaciones y buenas prácticas
Una migración limpia no se limita a evitar la caída. También puedes aprovechar el cambio de servidor para actualizar la instalación, documentarla mejor y reducir el riesgo en futuros movimientos. Lo que se hace bien una vez se hace mucho más rápido la próxima vez.
- Documenta las versiones, las rutas, los parámetros DNS y las excepciones técnicas.
- Mantén un plan de reversión corto, legible y ejecutable en pocos minutos.
- Elige una ventana de migración durante un tráfico bajo.
- Conserva copias de seguridad verificadas, no solo “hechas”.
- Monitorea los registros y métricas durante las horas posteriores al cambio.
En resumen, la migración de sitio sin tiempo de inactividad se basa menos en una herramienta mágica que en una secuencia limpia: inventario, respaldo, duplicación, pruebas, sincronización final, cambio DNS y verificación. Cuando cada paso está controlado, el cambio de servidor se convierte en una operación dominada, no en un salto al vacío.
Para recordar
Puntos clave para recordar:
🧭 La preparación reduce los errores invisibles incluso antes de copiar el sitio.
🛡️ El TTL DNS reducido a 300 segundos acelera una propagación más limpia.
🔁 La sincronización final protege los datos durante la transición.
⚙️ Las pruebas mediante hosts validan el nuevo servidor sin exponer a los visitantes.
🚑 El plan de reversión debe estar listo antes del cambio, nunca después.
Preguntas frecuentes
¿Cuánto tiempo se necesita para una migración de sitio sin tiempo de inactividad?
La duración depende principalmente del tamaño del sitio, el volumen de datos y el tiempo de prueba. La reducción del TTL suele requerir anticipar alrededor de 48 horas, luego el cambio en sí puede ser corto si todo se ha preparado correctamente.
¿Es necesario poner el sitio en mantenimiento?
No siempre. Para un sitio poco interactivo, un cambio bien preparado puede realizarse sin mostrar mantenimiento. Para una tienda o una aplicación con muchas escrituras, una congelación temporal de las acciones sensibles suele ser indispensable para evitar discrepancias de datos.
¿Por qué probar con el archivo hosts?
Porque permite ver el nuevo servidor antes de la propagación DNS pública. Puedes verificar las páginas, los formularios y los comportamientos dinámicos sin afectar a los visitantes ni modificar el dominio visible para todos.
¿Cuándo se debe activar la reversión?
Tan pronto como un problema afecte la coherencia de los datos, la seguridad o las funciones clave del sitio. Si dudas, es mejor volver al servidor antiguo y corregir tranquilamente que dejar una producción frágil funcionando.
¿Qué verificar después del cambio de DNS?
Controle el SSL, las redirecciones, las páginas dinámicas, los registros, los formularios y los correos electrónicos transaccionales. Si interviene una caché o un CDN, asegúrese de que sirva la versión del nuevo servidor y no un contenido obsoleto.
