[Inicio](https://hmbastion.com/es/) [Blog](https://hmbastion.com/es/blog/) Planificación Planificación 5 min de lectura # Migre el alojamiento con un cambio de sistema probado y un plan de reversión realista Una migración de alojamiento traslada un sistema en funcionamiento, no solo una carpeta. La parte difícil es mantener los datos coherentes mientras los usuarios, los procesos en segundo plano y las respuestas de DNS en caché aún pueden llegar a lugares diferentes. Un plan de cambio claro hace que esa transición sea revisable. Editorial de HM Bastion Publicado 2026-10-26 ## En esta guía - [Redacte el informe de migración antes de copiar datos](https://hmbastion.com/es/blog/hosting-migration-cutover-rollback/#write-migration-brief) - [Valide el destino sin modificar el tráfico público](https://hmbastion.com/es/blog/hosting-migration-cutover-rollback/#prove-destination) - [Haga que un solo sistema sea la autoridad para las escrituras](https://hmbastion.com/es/blog/hosting-migration-cutover-rollback/#choose-write-owner) - [Cambie el tráfico en una secuencia pequeña y observable](https://hmbastion.com/es/blog/hosting-migration-cutover-rollback/#switch-and-observe) - [Trate la reversión como una decisión sobre los datos y luego retire con cuidado](https://hmbastion.com/es/blog/hosting-migration-cutover-rollback/#define-rollback-boundary) [Todas las guías de hosting](https://hmbastion.com/es/blog/) ## La conclusión práctica Prepare y pruebe el destino, defina qué sistema puede aceptar escrituras, cambie el tráfico de forma deliberada y acuerde el límite de datos que hace segura una reversión. ## Redacte el informe de migración antes de copiar datos Inventaríe la versión de la aplicación, la base de datos, los archivos subidos, los secretos, las tareas programadas, el correo, DNS y las integraciones externas. Incluya los consumidores de colas y las devoluciones de llamada de los servicios de pago o de identidad. Identifique a la persona autorizada para cambiar cada componente. Una copia del sitio web correcta puede fallar igualmente si un proceso en segundo plano sigue operando en el host antiguo o si un webhook entrega a un endpoint retirado. Defina los criterios de aceptación en términos de usuario corrientes: un cliente puede iniciar sesión, ver un registro representativo, subir un archivo y completar una transacción sintética con integraciones de prueba aprobadas. Añada requisitos administrativos como copias de seguridad, monitorización y tareas programadas. Registre la ventana de mantenimiento prevista y el momento límite en que el equipo debe decidir si continúa o revierte. Confirme los recursos de destino y la región de alojamiento seleccionada antes de programar el traslado. Reserve espacio temporal para archivos, importaciones de bases de datos y el conjunto de trabajo de la aplicación. Si la asistencia de migración es relevante para el servicio adquirido, pida al soporte que confirme su alcance exacto y sus dependencias. No dé por hecho que el registro de dominios, todos los buzones y todos los ajustes de terceros se trasladan con un pedido de alojamiento. ## Valide el destino sin modificar el tráfico público Cree el destino con las versiones de software y de aplicación previstas. Restaure una copia de ensayo con el mismo método que piensa usar para el traslado final. Pruebe con el nombre de host real de la aplicación mediante una anulación local controlada o un entorno de pruebas aprobado, de modo que se ejerciten el enrutamiento del host y el comportamiento del certificado HTTPS. Visitar solo una dirección IP no demuestra que el nombre de host de producción vaya a funcionar. Mantenga el ensayo aislado de efectos secundarios reales. Desactive el envío de correo de producción, las acciones de pago reales, los webhooks salientes y las tareas programadas hasta que se haya revisado su comportamiento. Verifique los permisos del sistema de archivos, la gestión de subidas, la conectividad con la base de datos y las rutas de aplicación necesarias. Para WordPress, preste atención a las URL de sitio almacenadas y al comportamiento de los plugins; sustituir texto arbitrario de la base de datos puede dañar valores serializados. Realice un ensayo de restauración y anote el tiempo transcurrido. Una primera prueba que necesita dos horas de importación de datos no cabe en una ventana final de quince minutos sin explicación. Decida si la aplicación necesita un periodo de mantenimiento más largo, un traslado incremental compatible o un diseño distinto. El plan de migración debe reflejar el trabajo medido en lugar de tratar el cambio público de DNS como el proyecto completo. ## Haga que un solo sistema sea la autoridad para las escrituras | Fase | Autoridad de escritura | Evidencia requerida | | --- | --- | --- | | Preparación | Servicio de producción existente | El destino supera las comprobaciones de ensayo aislado | | Sincronización final | Escrituras pausadas o controladas por el diseño de migración | La base de datos, las subidas y las colas alcanzan un límite registrado | | Verificación del cambio | Solo el destino tras la aceptación | Las solicitudes y las integraciones llegan al servicio previsto | | Reversión tras nuevas escrituras | Elegida tras planificar la reconciliación | Los cambios recientes aceptados no se descartarán en silencio | Para una aplicación modesta, un intervalo planificado de solo lectura o de mantenimiento puede proporcionar un límite de datos final claro. Detenga o pause los escritores correspondientes, incluidos los procesos en segundo plano y las tareas de importación, y capture el estado final coherente de la base de datos y los archivos. Registre qué colas o eventos externos aún deben gestionarse. Una página de mantenimiento que bloquea los navegadores pero deja los procesos en segundo plano en ejecución no es una congelación completa de escrituras. Un diseño basado en replicación continua de bases de datos requiere su propio procedimiento de conmutación por error compatible y una validación cuidadosa. No improvise una sincronización bidireccional con una fecha límite encima. Dos copias de la aplicación con escritura independiente pueden generar pedidos, identificadores o subidas en conflicto. Elija el método de migración que el equipo haya ensayado y pueda explicar, aunque eso exija un periodo de mantenimiento más visible. ## Cambie el tráfico en una secuencia pequeña y observable Prepare con antelación los cambios de DNS. Si reduce el tiempo de vida de la caché (TTL) de un registro DNS, hágalo con la suficiente antelación para que caduquen las respuestas previamente almacenadas en caché con el tiempo de vida anterior. Un valor inferior introducido en el último momento no acorta las respuestas que ya se conservan en otros lugares. Mantenga controlados los endpoints antiguos y nuevos durante el solapamiento; cambiar DNS no supone una transferencia instantánea de todas las conexiones de cliente activas. - Confirme el límite final de los datos y la versión de la aplicación de destino. - Verifique HTTPS, las rutas importantes y la política de escritura prevista en el destino. - Cambie solo los registros de tráfico previstos y anote sus valores anteriores. - Compare las respuestas autoritativas de DNS con varias consultas recursivas independientes. - Compruebe recorridos de usuario representativos y observe errores, latencia y tráfico en ambos hosts. - Active cada worker o tarea programada aprobados exactamente una vez, en su host designado. Por ejemplo, un equipo pausa las escrituras a las 21:00, completa la sincronización final a las 21:15 y cambia los registros web a las 21:20. Verifica el destino antes de reabrir las escrituras a las 21:30. Esos horarios son una secuencia ilustrativa, no una duración estándar. El registro importante es el momento en que se aceptan por primera vez los nuevos cambios de los clientes en el destino. ## Trate la reversión como una decisión sobre los datos y luego retire con cuidado Antes de que el destino acepte nuevas escrituras, devolver el tráfico a un servicio antiguo que aún es coherente puede ser relativamente sencillo. Después, cambiar solo DNS de vuelta puede abandonar cambios aceptados. Decida si el destino puede repararse más rápido o si sus nuevos datos deben reconciliarse primero en el sistema antiguo. Mantenga la congelación de escrituras hasta que la autoridad de reversión elegida y el límite de los datos estén claros. Mantenga el servicio antiguo bajo un plan de retención deliberado en lugar de cancelarlo en cuanto funcione un navegador. Confirme que el tráfico residual, las dependencias de correo y las devoluciones de llamada ya no dependen de él. Verifique una copia de seguridad nueva del nuevo servicio de producción y complete una comprobación operativa final. Archive el registro de la migración para que un incidente posterior no dependa de que alguien recuerde qué servidor sigue siendo responsable de una tarea programada. Los ejemplos de productos usan el catálogo publicado de HM Bastion. La disponibilidad, los precios y las opciones seleccionables se muestran al configurar un pedido. ## Elija su próxima base. [Prepare los registros y TTL de DNS](https://hmbastion.com/es/blog/dns-records-ttl-cutover-checklist/) [Ensaye una restauración de la aplicación](https://hmbastion.com/es/blog/backup-restore-drill-rpo-rto/) [Comente el alcance de la migración](https://hmbastion.com/es/support/) ## Fuentes y lecturas adicionales - [WordPress: migrar una instalación](https://developer.wordpress.org/advanced-administration/upgrade/migrating/) - [Documentación de Cloudflare DNS: TTL y registros en caché](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) - [PostgreSQL: copia de seguridad lógica coherente](https://www.postgresql.org/docs/current/backup-dump.html) - [IETF RFC 1034: conceptos y almacenamiento en caché de DNS](https://www.rfc-editor.org/rfc/rfc1034) ## Siga explorando [ Planificación 5 min de lectura ## Ejecute Docker en un VPS con un plan operativo de producción Planifique los recursos de los contenedores, los datos persistentes, los puertos publicados, las versiones y los registros acotados antes de desplegar una aplicación Compose. ](https://hmbastion.com/es/blog/docker-vps-production-checklist/) [ Infraestructura 5 min de lectura ## Supervise un VPS con señales que conduzcan a una primera respuesta útil Cree un panel de servicio centrado, alertas accionables y una secuencia de diagnóstico inicial para errores, latencia y presión de recursos. ](https://hmbastion.com/es/blog/vps-monitoring-first-response/)