Cómo migrar un servidor local a AWS (guía simple)

Introducción

Las migraciones de on-prem a AWS fallan menos por problemas de computación y más por brechas en la planificación: objetivos de transición poco claros, dependencias pasadas por alto y pruebas apresuradas. Esta guía mantiene el proceso fácil de seguir mientras se mantiene operativo. Definirás cómo se ve el éxito, prepararás una zona de aterrizaje mínima, ejecutarás lanzamientos de prueba de AWS MGN, realizarás la transición con confianza y luego optimizarás la carga de trabajo una vez que esté en vivo.

¿Qué deberías decidir antes de migrar algo?

¿Qué estrategia de migración se adapta a este servidor (las "7 Rs" de AWS)?

La forma más rápida de perder tiempo es migrar lo incorrecto. Antes de instalar cualquier agente, decide qué estrategia de migración merece el servidor para que no levantes y traslades algo que debería ser retirado o reemplazado. En la práctica, muchos equipos comienzan con el rehosting por velocidad, y luego optimizan más tarde una vez que la carga de trabajo esté estable en AWS.

Sin embargo, eso solo funciona cuando el servidor es un buen candidato "tal como está" y no generará una deuda técnica costosa inmediatamente después de la transición. Atajos de decisión prácticos:

• Rehosting: moverse rápido con cambios mínimos cuando el tiempo es limitado.
• Replataforma: mantén la aplicación pero haz pequeños ajustes para que se adapte a AWS.
• Refactor: reserve esfuerzo para diferenciadores críticos para el negocio.
• Recompra: reemplazar con SaaS en lugar de migrar el servidor.
• Retirar/Conservar: eliminar sistemas no utilizados o mantener cargas de trabajo restringidas en las instalaciones.

Un punto de control interno útil es preguntar si la carga de trabajo tiene un "futuro en la nube". Si el servidor se descompondrá más tarde en servicios gestionados o en contenedores, documente eso ahora y trate el rehosting como un paso temporal en lugar de un diseño permanente.

¿Qué son el RTO/RPO, la ventana de inactividad y los desencadenantes de retroceso?

Las transiciones tienen éxito cuando el éxito es medible. Defina el tiempo de inactividad aceptable y la tolerancia a la pérdida de datos, luego anote las condiciones que obligan a la reversión. Esto mantiene el objetivo de la migración y evita que los equipos improvisen durante la ventana de transición. También ayuda a los interesados comerciales a aprobar, ya que pueden ver exactamente qué riesgo se está aceptando.

Definir y documentar:

• RTO: tiempo de inactividad máximo aceptable.
• RPO: pérdida de datos máxima aceptable.
• Ventana de inactividad: cuando se le permite cambiar el tráfico de producción.
• Desencadenantes de reversión: condiciones de fallo específicas (interrupción de autenticación, transacciones fallidas, desajuste de datos).
• Mecanismo de cambio: DNS flip, cambio de balanceador de carga, cambios de enrutamiento/firewall.

Para mantener el plan de reversión realista, especifique quién es el responsable de cada acción durante la transición. Por ejemplo, una persona es responsable de los cambios en DNS, otra de la validación de la aplicación y otra de la "decisión de reversión" basada en los desencadenantes anteriores.

¿Qué necesitas tener listo en AWS y en local primero?

Conectividad y conceptos básicos de firewall para replicación

La replicación solo funciona si el entorno de origen puede alcanzar AWS de manera consistente. Los bloqueadores más comunes son los controles de salida estrictos, los proxies y la inspección de TLS que interfieren con el tráfico HTTPS saliente. Valida la conectividad temprano y mantén el camino de red estable durante la replicación inicial y los lanzamientos de prueba. En muchos entornos, la replicación no está "bloqueada" por completo; en cambio, las caídas intermitentes o la inspección de paquetes causan un comportamiento inestable que es difícil de diagnosticar más tarde.

Patrones de conectividad comunes:

• Salida de internet pública (más simple cuando se permite)
• VPN de sitio a sitio (común para conectividad privada)
• Conexión Directa (más predecible para entornos más grandes)

Controles previos al vuelo:

• Outbound HTTPS funciona de manera confiable desde la red de origen
• El comportamiento del proxy se entiende y se prueba con el flujo de migración.
• Los equipos de seguridad aprueban la salida requerida para la ventana de migración.

Si su entorno está muy restringido, agregue un breve paso de "prueba de red" a su plan de ola: valide los puntos finales desde un servidor piloto, luego replique ese conjunto de reglas exacto para el resto de la ola.

Lista de verificación mínima de zona de aterrizaje de AWS

No necesitas una zona de aterrizaje perfecta para comenzar, pero sí necesitas un objetivo consistente que no cambie a mitad de la ola. Mantén la construcción mínima, pero deliberada, para que las pruebas reflejen cómo será el cambio. Muchos problemas de migración provienen de atajos de red "temporales" que se vuelven permanentes porque nadie tiene tiempo para reconstruirlos después del lanzamiento.

Elementos mínimos de la zona de aterrizaje:

• A VPC y subredes donde las instancias se lanzarán (a menudo pruebas separadas frente a producción)
• Grupos de seguridad alineado a los flujos de aplicación reales (evitar "abrir ahora, arreglar después")
• IAM listo para operaciones de migración y acceso y herramientas del día dos
• Básico etiquetado así que la propiedad y el seguimiento de costos son claros después de la transición

También ayuda a decidir temprano cómo los administradores accederán a las instancias (bastión, VPN , SSM) y cómo se proporcionará el acceso a internet saliente (puerta de enlace NAT, proxy). Estas elecciones afectan la aplicación de parches, los agentes de monitoreo y la solución de problemas desde el primer día.

Lista de verificación de preparación del servidor de origen

Una migración limpia depende de una fuente limpia. Confirma que la carga de trabajo sea compatible con el método que elegiste, luego identifica cualquier cosa que dependa de suposiciones locales que cambiarán en AWS. Este también es el lugar donde señalas los servidores de "caso especial" que pueden requerir una secuencia diferente. Por ejemplo, un servidor de archivos con una actividad de escritura intensa puede necesitar una ventana de cambio más ajustada y una validación más estricta para archivos y recursos compartidos abiertos.

Controles de preparación que previenen sorpresas:

• Compatibilidad de OS/carga de trabajo con el enfoque de migración
• Suficiente disco y E/S constante para la sobrecarga de replicación
• Dependencias mapeadas: DNS , AD/LDAP , interno PKI/certificados , bases de datos, acciones
• Fragilidad oculta: IPs codificadas, TLS heredado, tareas programadas poco comunes
• Casos especiales señalados temprano: controladores de dominio, clústeres, dispositivos, licencias de dongle

Antes de dejar este paso, captura los elementos que "deben permanecer iguales", como el nombre del host, los requisitos de dirección IP o las vinculaciones de certificados, porque estos afectan directamente la configuración de lanzamiento de AWS y tu secuencia de cambio.

¿Cómo migrar un servidor a AWS con AWS MGN?

Inicializar MGN y establecer los valores predeterminados de replicación

Inicializa AWS MGN en la región donde se ejecutará el servidor, luego define los valores predeterminados de replicación para que la ejecución de la ola se mantenga consistente. Una plantilla estable reduce la variación por servidor y hace que la solución de problemas sea repetible. Piensa en esto como tu procedimiento operativo estándar para la replicación, similar a una imagen dorada en un entorno virtualizado.

Establecer los valores predeterminados de replicación de antemano:

• Estrategia de subred objetivo y ubicación de red
• Grupo de seguridad base para instancias lanzadas
• Comportamiento de almacenamiento (mapeo de volumen, cifrado expectativas)
• Limitación de replicación para proteger el tráfico de producción

Si ya sabe que la producción requerirá configuraciones diferentes a las de prueba, defina esas diferencias de manera explícita. De esa manera, los lanzamientos de prueba seguirán siendo representativos sin exponer prematuramente las redes de producción.

Instalar el agente y completar la sincronización inicial

Instale el agente de replicación en el servidor de origen y confirme que se registre correctamente. La sincronización inicial es donde la inestabilidad le cuesta más, así que evite cambios innecesarios y supervise de cerca la salud de la replicación. También es donde los equipos se benefician de documentar el flujo de instalación "conocido como bueno" para que no solucionen los mismos problemas en cada ola.

Guía operativa:

• Mantener el servidor estable durante la replicación inicial (evitar reinicios si es posible)
• Monitorear el estado de replicación y abordar errores de inmediato
• Documentar el método de instalación para que las futuras oleadas sean consistentes.

Durante la sincronización inicial, monitorea no solo la consola de migración, sino también el rendimiento del servidor. La sobrecarga de replicación puede revelar cuellos de botella en el almacenamiento o errores de disco que anteriormente estaban enmascarados en el entorno local.

Lanza una instancia de prueba y valida

Un lanzamiento de prueba convierte suposiciones en evidencia. Lance la instancia de prueba, luego valide la salud de la aplicación de extremo a extremo, no solo el éxito del arranque. Utilice una lista de verificación para que las pruebas sean repetibles en servidores y oleadas. Si los usuarios finales se conectarán a través de TSplus Acceso Remoto incluya una verificación de la ruta de acceso en la validación. La consistencia es importante porque le permite comparar resultados entre cargas de trabajo y detectar patrones, como problemas de resolución de DNS que afectan a múltiples servidores.

Lista mínima de verificación de validación:

• El arranque se completa y los servicios inician correctamente.
• Las pruebas de humo de la aplicación pasan para flujos de trabajo clave
• La autenticación funciona (AD/LDAP/local)
• Las rutas de datos funcionan (conexiones de base de datos, recursos compartidos de archivos, integraciones)
• Los trabajos programados y los servicios en segundo plano se ejecutan como se esperaba.
• Registros y señales de monitoreo aparecer donde su equipo de operaciones los espera

Agrega un paso más que los equipos a menudo omiten: valida cómo los usuarios accederán realmente a la aplicación, incluyendo el enrutamiento interno, las reglas del firewall y cualquier sistema ascendente. Un servidor puede estar "saludable" pero ser inalcanzable en la práctica.

Lanzar la transición y finalizar

El corte es un cambio controlado, no un salto de fe. Congela los cambios, cuando sea posible, ejecuta el movimiento de tráfico utilizando el mecanismo planificado, luego valida utilizando la misma lista de verificación que en las pruebas. Mantén la propiedad de reversión explícita para que las decisiones sean rápidas. Trata esto como un manual repetible: cuanto menos improvises, menor será el riesgo.

Esenciales de ejecución de corte:

• Confirmar el plan de congelación de cambios y comunicaciones
• Lanzar instancia de cambio y cambiar tráfico (DNS/LB/ruteo)
• Reejecutar la lista de verificación de validación con un enfoque adicional en la integridad de los datos
• Aplicar desencadenadores de reversión si es necesario y revertir el tráfico de manera limpia
• Finalizar la transición y eliminar o terminar los recursos de prueba

Inmediatamente después de la transición, captura lo que cambió en producción (nuevas IP, nuevas rutas, nuevas reglas de grupo de seguridad) y documenta esto. Esta es la información que el equipo de operaciones necesita cuando algo falla semanas después.

¿Qué suele fallar y qué deberías hacer justo después de la transición?

Egreso de red, dependencias de DNS/AD y "el levantamiento y traslado no se ha realizado"

La mayoría de las fallas son fallas de dependencia. La replicación tiende a romperse en las restricciones de salida y proxy, mientras que el comportamiento de la aplicación tiende a romperse en la identidad, la resolución de nombres y los certificados. Incluso cuando la transición tiene éxito, el rehosting es solo el primer hito, no el estado final. Sin una segunda fase, a menudo terminas con "legado alojado en la nube" que cuesta más y es más difícil de operar.

Puntos de interrupción más comunes:

• HTTPS saliente bloqueado o alterado por proxy inspección TLS
• Cambios en la resolución de DNS (problemas de horizonte dividido, reglas de resolutor ausentes)
• Gaps de accesibilidad de AD/LDAP desde el VPC
• Cadenas PKI internas faltantes o no confiables en el nuevo entorno
• Puntos finales codificados y suposiciones heredadas sobre rutas de red locales

Una mitigación simple es probar la identidad y DNS temprano con un lanzamiento piloto. Si esos fundamentos funcionan, el resto de la validación de la aplicación se vuelve mucho más predecible.

Estabilización post-cambio: seguridad, copias de seguridad, monitoreo, costo

Las primeras 48 horas después de la transición deben priorizar la estabilidad y el control. Asegúrese de que la carga de trabajo sea observable, recuperable y gestionada de manera segura antes de dedicar tiempo a una optimización más profunda. Aquí es donde su migración tiene éxito a largo plazo, porque unas buenas operaciones en el segundo día previenen resultados de "lo movimos, pero nadie quiere hacerse cargo".

Acciones inmediatas después de la transición:

• Confirme que la supervisión/alerta está activa y es de su propiedad
• Asegúrese de que las copias de seguridad estén habilitadas y complete una validación de restauración.
• Ajustar los grupos de seguridad y aplicar el principio de menor privilegio IAM
• Estandarizar el enfoque de parches y el acceso administrativo (rutas auditables)
• Comience a ajustar el tamaño después de recopilar datos de utilización reales.
• Hacer cumplir el etiquetado para prevenir la desviación de costos de "propietario desconocido"

Una vez que se haya demostrado la estabilidad, programe una breve revisión de optimización para cada servidor migrado. Incluso un ligero repaso sobre los tipos de almacenamiento, la elección de la familia de instancias y la estrategia de capacidad reservada puede reducir materialmente el costo.

¿Dónde encaja TSplus después de mover servidores a AWS?

Después de que las cargas de trabajo de Windows se ejecuten en AWS, muchos equipos aún necesitan una forma sencilla de publicar aplicaciones y escritorios de Windows a los usuarios sin construir una pesada pila de VDI. TSplus Acceso Remoto ofrece publicación de aplicaciones y acceso a escritorio remoto para servidores Windows en AWS, en las instalaciones o en entornos híbridos, con una administración sencilla y una licencia predecible que se adapta a las operaciones de las pequeñas y medianas empresas y del mercado medio.

Conclusión

Migrar un servidor local a AWS es más exitoso cuando sigue un libro de procedimientos repetible: elige la estrategia de migración adecuada, valida las dependencias, replica de forma segura, prueba de manera realista y realiza el cambio con desencadenantes de reversión claros. Una vez que la producción esté estable, cambia el enfoque a las operaciones del segundo día: endurecimiento de la seguridad, validación de copias de seguridad, monitoreo y ajuste de tamaño. Esto convierte un "movimiento" en una plataforma confiable y controlada en costos.