Guía · Nube
Guía de migración a la nube para grandes empresas, de la evaluación a la transición
Una migración es una secuencia de decisiones, la mayoría de las cuales se toman antes de mover un solo servidor. Este manual expone las fases, la elección de región y la residencia de los datos, y las prácticas que permiten que el fin de semana de la transición transcurra sin sobresaltos.
Para qué sirve un manual
Las grandes empresas rara vez migran una sola vez. Migran un primer sistema, aprenden de él y después migran los diez siguientes. Un manual recoge lo aprendido para que la segunda ola sea más rápida y segura que la primera: cómo se evalúan los sistemas, cómo es la landing zone, cómo se ejecuta una transición y qué significa “terminado”. Esta guía es la que utilizamos como punto de partida con nuestros clientes; conviene adaptarla a su organización en lugar de seguirla al pie de la letra.
La recorren dos principios. Primero, migrar la función de negocio y no el servidor: la cuestión es cómo una aplicación y sus datos siguen dando servicio a los usuarios, no cómo se copia una máquina virtual. Segundo, mantener cada paso reversible hasta el momento en que se decida deliberadamente hacerlo permanente.
Las fases
Cada fase termina con una decisión que el comité de dirección puede identificar. Las fases se superponen entre olas: la segunda ola se evalúa mientras migra la primera.
- 1
Evaluar
Inventaríe cada aplicación con su responsable, dependencias, clasificación de datos, integraciones, licencias e infraestructura actual. Agrupe las aplicaciones en olas según sus dependencias y su riesgo. Decida el destino de cada una: rehost (trasladarla tal cual), replatform (cambios menores, como una base de datos gestionada), refactor (contenedorizarla o rediseñar su arquitectura), replace (SaaS) o retire (retirarla). Resultado: un plan de olas con los destinos y el primer caso de negocio.
- 2
Planificar
Para la primera ola, diseñe la arquitectura de destino, la ruta de red desde sus instalaciones, la identidad (SSO para las personas, roles para las cargas de trabajo), el método de migración de datos y el patrón de transición de cada aplicación. Redacte los criterios de aceptación en esta etapa: qué pruebas, qué usuarios y qué informes deben coincidir. Resultado: un diseño por aplicación y el esqueleto de un runbook.
- 3
Construir la landing zone
Cree como código la estructura de cuentas, la red, la identidad, el registro, las líneas base de seguridad, las copias de seguridad y los controles de costos antes de que llegue cualquier carga de trabajo. Es la base sobre la que se apoyarán todas las olas posteriores, por lo que vale la pena construirla bien una sola vez. Resultado: un entorno gestionado con Terraform que supera sus propias comprobaciones de cumplimiento.
- 4
Migrar por olas
Traslade primero los entornos que no son de producción y después producción, una ola cada vez. Replique los datos de forma continua cuando el patrón lo requiera, ejecute las pruebas de aceptación en el destino con datos reales y corrija lo que falle antes de que afecte a nadie más. Resultado: un entorno de destino que ha superado la aceptación mientras el sistema anterior sigue en funcionamiento.
- 5
Realizar la transición
Ejecute el runbook ensayado: congele los cambios, complete la sincronización final de datos, cambie el tráfico, verifique y comunique. Mantenga el entorno de origen intacto y listo para una reversión durante un período acordado. Resultado: producción funcionando en el destino, con el punto de decisión sobre la reversión superado de forma explícita.
- 6
Optimizar
Tras la estabilización, se ajusta lo que se sobredimensionó por seguridad, se trasladan las cargas de trabajo aptas a servicios administrados o contenedores, se aplican precios por compromiso donde el uso es predecible y se da de baja el sistema de origen. Resultado: una línea base del costo de operación y las lecciones incorporadas al manual para la siguiente oleada.
Selección de región y residencia de datos
La elección de región va primero. Una región dentro del país, cuando existe, ofrece varias zonas de disponibilidad para la resiliencia y baja latencia para los usuarios locales. La Región AWS Asia Pacific (Bangkok) (ap-southeast-7) es un ejemplo: ofrece a las organizaciones con usuarios en Tailandia una opción que no existió durante la mayor parte de la era de la nube, en lugar de atender al país desde Singapur. Para los sistemas sensibles a la latencia y para las organizaciones cuyas políticas o reguladores prefieren que los datos permanezcan en el país, una región nacional es el punto de partida por defecto.
Conviene tener en cuenta dos precauciones. Las regiones más nuevas no se lanzan con todos los servicios; consulte la lista de servicios de la región para cada servicio gestionado del diseño antes de comprometerse, y prepare una alternativa (otro servicio u otra región para ese componente). La residencia es además una decisión de política antes que técnica: la legislación de protección de datos personales, como la PDPA, permite la transferencia internacional bajo determinadas condiciones, y los reguladores sectoriales, por ejemplo en servicios financieros, pueden tener sus propias exigencias. Deje por escrito qué categorías de datos deben permanecer en el país y cuáles pueden replicarse en el extranjero para la recuperación ante desastres, y pida a los equipos jurídico y de cumplimiento que lo confirmen. Después, plásmelo como restricciones de región en las políticas de la organización, de modo que un recurso mal ubicado se impida en lugar de descubrirse después.
La recuperación ante desastres merece la misma claridad. Dentro de la región, varias zonas de disponibilidad protegen frente a la falla de una instalación. Para protegerse frente a un incidente que afecte a toda la región, decida si es aceptable una segunda región para copias de seguridad o un entorno en espera, cuál debe ser esa región y qué tiempo y punto de recuperación está dispuesto a financiar el negocio.
Terraform: la landing zone como código
Todo lo que en la landing zone pueda definirse como código debe definirse así: cuentas y políticas organizativas, redes y enrutamiento, identidad y roles, registros y pistas de auditoría, claves de cifrado, políticas de copia de seguridad, presupuestos y alertas. Terraform es nuestra herramienta preferida porque es declarativa, independiente del proveedor y revisable en el mismo flujo de pull requests que el código de las aplicaciones.
Algunas prácticas lo mantienen manejable. Guarde el estado de forma remota y con bloqueo, un estado por entorno y por componente lógico, para que un error en un lugar no pueda dañar otro. Cree módulos pequeños y con nombres claros para lo que se crea repetidamente (un servicio con su definición de contenedor, regla del balanceador de carga, rol de IAM y grupo de logs) y versiónelos. Etiquete cada recurso con su responsable, entorno, aplicación y centro de costos desde un único módulo de etiquetado, porque el control de costos dependerá de ello más adelante. Ejecute un plan con cada cambio, exija revisión y aplique los cambios desde un pipeline, no desde un portátil. Detecte las desviaciones de forma programada y trate los cambios manuales en la consola como incidentes que hay que conciliar, no como la nueva normalidad.
El resultado es que el entorno para la segunda ola es un pull request, no un proyecto.
Comparación de patrones de transición
Elija un patrón por aplicación, no por programa. La tolerancia a la interrupción, el volumen de datos y la forma en que el tráfico llega al sistema determinan qué patrón conviene.
| Patrón | Cómo funciona | Más adecuado para | Interrupción y reversión |
|---|---|---|---|
| Big-bang (sin conexión) | Detener el origen, copiar los datos, iniciar el destino y cambiar el DNS o los endpoints. | Sistemas pequeños, cargas de trabajo por lotes y herramientas internas con una ventana de mantenimiento. | La interrupción equivale al tiempo de copia. La reversión es sencilla: volver a apuntar al origen intacto. |
| Replicar y luego cambiar | Replicación continua de la base de datos hacia el destino (por ejemplo, con un servicio de replicación gestionado) mientras el origen sigue en funcionamiento; sincronización final y cambio en el momento de la transición. | Bases de datos y ERP en los que una interrupción larga es inaceptable, pero una breve es tolerable. | Minutos de interrupción. La reversión requiere replicación inversa o aceptar la pérdida de los datos generados desde el cambio; decídalo de antemano. |
| Blue-green | Entorno de destino completamente construido y probado junto al origen; el tráfico se cambia en el balanceador de carga o en el DNS en un solo paso. | Cargas de trabajo sin estado y de capa web; aplicaciones cuya capa de datos ya se ha trasladado. | Casi nula. La reversión es el mismo cambio en sentido inverso, siempre que la capa de datos esté compartida o sincronizada. |
| Canary / ponderado | Una pequeña parte del tráfico (por peso, región o grupo de usuarios) se envía al destino y se aumenta a medida que crece la confianza. | Aplicaciones de cara al cliente con muchos usuarios; permite detectar problemas antes de que los vean todos. | Ninguna, por diseño. La reversión consiste en reducir el peso. Requiere gestión de sesiones y coherencia de datos entre ambos lados. |
| Strangler (incremental) | Redirigir una función cada vez a nuevos servicios en el destino; el sistema heredado se reduce hasta su retirada. | Grandes monolitos en proceso de refactorización; programas de modernización de varios años. | Ninguna en cada paso. La reversión se hace por función. Es el más lento en conjunto y el de menor riesgo por cambio. |
Ensayar la reversión
Todos los runbooks tienen una sección de reversión; pocos equipos la han ejecutado. Ensaye la transición completa al menos una vez en un entorno que no sea de producción, con las mismas personas, la misma lista de comprobación y un cronómetro, y después ensaye la reversión. Defina los criterios de continuar o abortar antes del día señalado (qué pruebas deben superarse, qué partes interesadas deben confirmar y antes de qué hora) y designe a la única persona que toma la decisión. Fije de forma explícita el punto de no retorno: el momento a partir del cual las nuevas transacciones existen solo en el destino y revertir implica conciliar los datos manualmente.
Durante la transición real, comunique según un calendario fijo y no solo cuando ocurra algo: un mensaje de estado cada treinta minutos, aunque solo informe de que el trabajo avanza según lo previsto, mantiene la calma en el negocio y la concentración en el equipo. Después, celebre una breve revisión mientras los detalles están recientes y actualice el manual.
Control de costos desde el primer día
Las facturas de la nube crecen por inercia y solo bajan cuando alguien se hace responsable de ellas. Incorpore estos controles antes de la primera carga de trabajo en producción.
- Presupuestos con alertas por cuenta y por aplicación, visibles tanto para el responsable de la aplicación como para finanzas.
- Etiquetas obligatorias impuestas mediante políticas, para que todo el gasto pueda atribuirse.
- Entornos que no son de producción apagados de forma programada fuera del horario laboral, o creados bajo demanda con Terraform.
- Revisiones de dimensionamiento un mes después de cada ola, porque las migraciones se dimensionan pensando en la seguridad, no en la eficiencia.
- Precios con compromiso de uso (planes de ahorro o capacidad reservada) solo cuando el consumo sea estable y se comprenda bien.
- Reglas de ciclo de vida del almacenamiento: los logs, las copias de seguridad y las instantáneas pasan a niveles más económicos y caducan según un calendario.
- Servicios gestionados y contenedores cuando el ahorro operativo es real; rediseñar la arquitectura no es una condición previa para reducir costos.
- Una revisión mensual de costos con el mismo rigor que la revisión de disponibilidad.
Una segunda opinión sobre su plan de olas
Compártanos su plan de olas y le diremos qué haríamos de otra manera. Nuestro equipo de nube e infraestructura construye entornos de AWS gestionados con Terraform y ejecuta migraciones para grandes empresas, también hacia la Región AWS Asia Pacific (Bangkok).