Cómo migrar el servidor de un sitio web sin tiempo de inactividad
Publicado el 15 de julio de 2026
Inicie la migración con una copia de seguridad completa y restaurable, y un plan de cambio por escrito. Esa es la respuesta más segura a cómo migrar la infraestructura del servidor de un sitio web sin convertir un traslado rutinario en una interrupción del servicio. Su nuevo servidor debe estar construido, protegido y probado antes de que el DNS dirija visitantes hacia él. El servidor antiguo permanece en línea hasta que el nuevo entorno haya superado comprobaciones reales.
Una migración de servidor es más que copiar archivos del sitio web. El sitio web, la base de datos, las tareas programadas, el enrutamiento del correo, los certificados SSL, el entorno de ejecución de la aplicación, el comportamiento de la caché, los registros DNS y las reglas de firewall pueden formar parte del servicio. Omitir una pequeña dependencia es lo que puede hacer que un sitio parezca funcionar bien en la página de inicio mientras los correos de compra, los formularios o los trabajos en segundo plano fallan silenciosamente. No es un fallo muy glamuroso, pero sigue siendo costoso.
Mapee el servidor actual antes de moverlo
Empiece con un inventario de lo que realmente está en ejecución. No dependa solo de lo que muestre el panel de control del hosting. Revise la raíz de documentos, la versión de la aplicación, el motor y la versión de la base de datos, la configuración de PHP o Node.js, los trabajos cron, los workers de cola, las rutas de almacenamiento, las redirecciones, las variables de entorno y la configuración del correo saliente.
En un sitio web empresarial, identifique también todo lo que esté fuera del dominio principal. Esto puede incluir subdominios, sitios de staging, endpoints de API, callbacks de pago, almacenamiento de objetos, proveedores de correo de terceros, scripts de analítica y registros DNS usados para verificación. Si el servidor envía correo directamente, registre su IP de envío, la configuración de reverse DNS y los registros SPF, DKIM y DMARC. El correo electrónico suele ser el último elemento en notarse y el primero del que se quejan los clientes.
Documente también el uso de recursos del servidor actual. Revise la carga de CPU, el consumo de memoria, el espacio en disco, el tamaño de la base de datos, los patrones de tráfico y los registros de errores. Esto le indica si el nuevo VPS o servidor dedicado tiene el tamaño adecuado. Una migración es un buen momento para dejar atrás un disco demasiado pequeño, una versión obsoleta de PHP o un servidor que ha estado sobreviviendo principalmente gracias al optimismo.
Prepare primero el nuevo entorno
Aprovisione el servidor de destino antes de copiar los datos de producción. Aplique actualizaciones del sistema operativo, cree acceso administrativo restringido, configure el firewall e instale solo los servicios que el sitio necesita. Use claves SSH en lugar de acceso solo con contraseña siempre que sea posible. Desactive los servicios innecesarios y asegúrese de que las actualizaciones automáticas de seguridad se ajusten a su política operativa.
Haga coincidir cuidadosamente los requisitos de la aplicación. Un sitio que pasa de PHP 7.4 a PHP 8.3, o de MySQL a una versión más reciente de MariaDB, puede necesitar cambios en el código antes de funcionar correctamente. Lo mismo se aplica a la configuración del servidor web. Las reglas de reescritura de Apache, las ubicaciones de Nginx, los permisos de archivos y las extensiones de PHP no siempre se traducen de forma directa.
Configure la monitorización antes del cambio, no después de un incidente. Supervise la disponibilidad, el tiempo de respuesta, la CPU, la memoria, el uso del disco, el vencimiento del SSL y los puertos de servicios clave. En aplicaciones con procesamiento en segundo plano, supervise también la profundidad de la cola y los trabajos fallidos. Con infraestructura gestionada y monitorización en su lugar, los registros cuentan la misma historia desde el principio, en lugar de obligarle a adivinar después de que los visitantes informen de un problema.
Haga copias de seguridad para recuperar, no solo para sentirse tranquilo
Cree una copia de seguridad nueva inmediatamente antes de la ventana de migración. Debe incluir archivos del sitio web, bases de datos, archivos de configuración, cargas generadas por usuarios y cualquier secreto de la aplicación almacenado fuera de la raíz web. Verifique que la copia de seguridad pueda restaurarse en una ubicación separada. Una copia de seguridad que nunca se ha probado es un archivo esperanzador, no un plan de recuperación.
Para las bases de datos, use una exportación coherente. Las bases de datos grandes o activas pueden requerir un manejo especial para evitar copiar datos mientras están cambiando. Según la base de datos y la aplicación, puede usar una ventana de mantenimiento, un modo de solo lectura, replicación o una sincronización incremental final. Las tiendas de comercio electrónico, los sistemas de reservas, los productos SaaS y los sitios de membresía requieren un cuidado especial porque los pedidos y los cambios de cuenta pueden llegar cada minuto.
Mantenga el servidor original sin cambios durante el traslado. No lo cancele ni borre los datos tan pronto como los archivos aparezcan en el destino. Conservar el entorno antiguo le da una ruta de reversión limpia si aparece una dependencia oculta después del cambio.
Transfiera archivos y bases de datos por etapas
Copie el conjunto inicial de datos mientras el sitio existente sigue activo. Las herramientas de transferencia segura de archivos, como rsync sobre SSH, son útiles porque pueden sincronizar solo los archivos modificados durante una pasada final posterior. Para las bases de datos, importe el volcado inicial en el nuevo servidor y luego pruebe la aplicación contra él usando un nombre de host temporal o una anulación local del archivo hosts.
Evite probar solo la página principal. Inicie sesión como administrador y como usuario normal. Envíe un formulario de contacto, restablezca una contraseña, cargue un archivo, haga una compra de prueba si corresponde, revise los correos de transacciones y confirme que las tareas programadas estén funcionando. Revise los registros de la aplicación y los registros de errores del servidor web durante las pruebas. Una respuesta HTTP 200 correcta no demuestra que el servicio esté saludable.
Si está cambiando también la arquitectura del servidor, aísle los cambios siempre que sea posible. Por ejemplo, mudarse a un nuevo VPS ya es suficiente trabajo sin rediseñar también la base de datos, sustituir la capa de caché y actualizar el framework de la aplicación en una sola noche. Separar los proyectos hace que los fallos sean más fáciles de diagnosticar y revertir.
Reduzca el TTL de DNS antes del cambio
DNS es donde una migración técnicamente exitosa puede volverse confusa para los visitantes. Reduzca el TTL de los registros A, AAAA, CNAME y relacionados con el correo entre 24 y 48 horas antes del cambio planificado. Un TTL más bajo anima a los resolvers a actualizar los registros más rápido una vez que apunte el dominio al nuevo servidor.
Esto no garantiza que todos los resolvers se actualicen al instante. Algunas redes almacenan en caché durante más tiempo del solicitado, y los usuarios pueden tener caché DNS local. Planifique un período de transición en el que una pequeña parte del tráfico aún pueda llegar al servidor antiguo. Si el sitio acepta datos cambiantes, necesita una estrategia para esa superposición. Un modo de mantenimiento durante la sincronización final suele ser más seguro que aceptar nuevos pedidos en dos servidores separados.
No cambie los nameservers a menos que también haya una razón para mover el hosting DNS. Cambiar los nameservers autoritativos añade otra capa de propagación y más registros para validar. Mantenga la migración aburrida siempre que pueda. La infraestructura aburrida suele ser una infraestructura saludable.
Ejecute la sincronización final y cambie el tráfico
En el momento de cambio acordado, ponga la aplicación en modo de mantenimiento si escribe datos de clientes. Detenga los workers de cola y las tareas programadas en el servidor antiguo para que no puedan procesar la misma tarea dos veces. Ejecute la sincronización final de archivos y la exportación/importación de la base de datos, y luego actualice la configuración de destino con las credenciales de la base de datos de producción, las claves de la aplicación y las URL correctas.
Habilite la aplicación en el nuevo servidor y actualice el DNS a su dirección IP. Confirme que el certificado SSL esté instalado y que HTTP redirija a HTTPS correctamente. Si hay un balanceador de carga, CDN o proxy delante del sitio, actualice su configuración de origen y verifique que reconozca las comprobaciones de estado del nuevo servidor.
Supervise ambos servidores durante la propagación. El nuevo servidor debería mostrar solicitudes entrantes, mientras que el servidor antiguo debería recibir cada vez menos tráfico. Revise los errores 404, 500 y de permisos, así como las alertas específicas de la aplicación. Vigile el uso de recursos porque un nuevo servidor puede comportarse de forma diferente con tráfico real que durante las pruebas.
Valide el servicio después de la migración
Una vez que el tráfico llegue al nuevo entorno, realice una comprobación de producción centrada. Confirme que las páginas principales cargan, que los usuarios pueden autenticarse, que los formularios se envían, que los flujos de pago o reserva funcionan, que los paneles muestran datos actuales y que los archivos cargados son accesibles. Pruebe desde más de una red si es posible, ya que su propio equipo todavía puede tener DNS en caché.
Revise la actividad programada durante las siguientes horas. Los trabajos cron, las copias de seguridad, las renovaciones, los informes, los workers de cola y los receptores de webhooks exponen con frecuencia problemas de migración después de que la validación inicial haya sido superada. Revise también los registros de correo y los informes de entrega. Si el sitio usa un servicio SMTP remoto, confirme que la IP o el nombre de host del nuevo servidor esté autorizado.
Deje el servidor antiguo disponible durante al menos 48 a 72 horas; más tiempo en aplicaciones complejas o entornos DNS lentos. Durante ese período, conserve las copias de seguridad de ambos lados y no haga cambios de configuración no relacionados. Una vez que la monitorización esté limpia, el tráfico sea estable y la ventana de reversión haya pasado, retire de servicio el servidor antiguo de forma segura.
Sepa cuándo usar ayuda gestionada
Un sitio informativo sencillo normalmente puede trasladarse con una preparación cuidadosa y una ventana de mantenimiento corta. Una tienda con mucho tráfico, un portafolio de agencia con muchos sitios de clientes, una plataforma SaaS o un servidor con servicios personalizados merecen un plan más controlado. La replicación de bases de datos, los despliegues por etapas, el drenaje de tráfico y la monitorización activa reducen el riesgo, pero también necesitan manos experimentadas.
kodu.cloud puede ayudar con el lado operativo de una migración, desde la preparación y las copias de seguridad del servidor de destino hasta la monitorización y la validación. El objetivo no es hacer que el proceso parezca misterioso. Es garantizar que alguien esté vigilando la infraestructura mientras usted mantiene el negocio en marcha.
Una buena migración termina en silencio: los visitantes usan el sitio, los trabajos programados se ejecutan, las copias de seguridad se completan y nadie tiene que enviar un mensaje nervioso a todo el equipo. Conserve el plan, la copia de seguridad y el servidor antiguo hasta que las pruebas indiquen que el servicio vuelve a estar tranquilo.
Andres Saar Ingeniero de Atención al Cliente