Las migraciones a la nube no fallan por la tecnología: fallan porque nadie se sentó a definir qué se movía primero, qué dependía de qué, y qué pasaba si algo salía mal durante el corte. La plataforma en sí —AWS, Azure o la que sea— rara vez es el problema; el problema es cortar producción sin un inventario claro, sin plan de reversa y sin un criterio de aborto definido de antemano. Esta checklist organiza lo que hay que resolver antes, durante y después del corte, para que la operación —turnos, facturación, planta— no se detenga mientras el sistema se mueve.
Antes de mover nada: inventario y dependencias
Ninguna migración empieza en el servidor. Empieza con un inventario honesto de lo que existe y de cómo se usa hoy, no de cómo dice el diagrama que debería usarse:
- Qué sistemas existen y quién los usa realmente en el día a día — no el organigrama, sino los equipos que dependen de cada aplicación para operar.
- Dependencias entre aplicaciones: qué se rompe si un sistema se mueve antes que otro (integraciones, reportes automáticos, procesos por lote).
- Ventanas reales de operación: turnos de planta, cierres contables, temporadas altas — momentos en los que un corte simplemente no es viable.
- Licencias y contratos vigentes: qué software depende de un servidor físico, un dongle o un acuerdo que no se traslada solo a la nube.
- Quién es dueño de cada dato: sin un responsable claro por sistema, nadie valida después si la migración se hizo bien o si algo se perdió en el camino.
Decide qué migrar y en qué orden
No todo se migra igual. Hay sistemas que se pueden mover tal cual, sin tocar su arquitectura (rehost); otros conviene ajustarlos a las ventajas de la nueva plataforma sin rediseñarlos por completo (replatform); y algunos —generalmente los más viejos o los que ya no soportan la operación actual— vale la pena rediseñarlos de raíz (refactor). La pregunta no es cuál técnica es mejor en abstracto, sino cuál sistema necesita cuál tratamiento.
El orden importa más que la técnica: empieza por lo que hoy genera más molestia operativa pero implica bajo riesgo si algo sale mal —un servidor de archivos, un ambiente de pruebas, una aplicación secundaria—. Nunca arranques por el sistema más crítico: ahí es donde menos margen hay para aprender sobre la marcha, y los errores de aprendizaje deben pagarse en un sistema que la operación pueda perdonar.
El plan de reversa no es opcional
Un respaldo que nunca se ha restaurado no es un respaldo: es una suposición. Antes de mover nada, hay que probar la restauración completa en un ambiente aislado y confirmar que los datos llegan íntegros y utilizables, no solo que el archivo del respaldo existe.
El criterio de aborto se define antes del corte, no durante: qué señales obligan a revertir (errores de datos, caída de un sistema dependiente, un corte que se alarga más de lo planeado) y quién tiene la autoridad para tomar esa decisión con la información disponible en ese momento —no después, con el beneficio de la retrospectiva—.
La ventana de corte, paso a paso
- Congelar cambios en el sistema origen para que no haya movimiento de datos a mitad del corte.
- Sincronizar los datos finales entre el origen y el destino.
- Validar en el destino con casos reales de uso, no solo con pruebas sintéticas.
- Hacer el corte: redirigir DNS, conexiones y accesos hacia el nuevo entorno.
- Monitorear con todo el equipo disponible, no solo con quien lideró la migración.
- Confirmar el corte o revertir, según el criterio de aborto acordado desde antes.
Costos: la nube no es barata por default
La nube factura por lo que usas, no por lo que aprovisionas una sola vez —y eso es una ventaja solo si se dimensiona bien—. Dimensiona según el uso real de tu operación, no según el pico histórico que ocurrió una vez hace dos años; sobredimensionar "por si acaso" es la forma más común de que una migración a la nube termine costando más que la infraestructura que reemplazó.
Apaga los ambientes de prueba y desarrollo fuera de horario: no necesitan estar encendidos si nadie los usa de noche o en fin de semana. Configura alertas de presupuesto desde el primer día, no hasta que llegue una factura inesperada. Y revisa el gasto mensual con la misma disciplina con la que se revisa cualquier otro insumo de la operación —como el consumo de energía o la materia prima—, no como una línea que se aprueba sin mirar.
Después del corte: validar y operar
El corte no es el final del proyecto: es el inicio de la operación en el nuevo entorno. Verifica que el monitoreo y las alertas quedaron configurados para el destino —no solo copiados del ambiente anterior, sino ajustados a la nueva arquitectura—. Revisa accesos y permisos: una migración es el mejor momento para depurar cuentas y privilegios que ya no deberían existir. Confirma que los respaldos están operando en el destino, y no que siguen apuntando al servidor que ya se apagó.
Documenta cómo opera el nuevo ambiente para que no dependa de la memoria de quien hizo la migración: aquí es donde la automatización y DevOps marcan la diferencia entre una migración que se sostiene sola y una que empieza a acumular deuda técnica desde el primer día.
Cada uno de estos puntos se puede planear con más o menos detalle según el tamaño de la operación, pero ninguno se puede saltar sin asumir un riesgo que, tarde o temprano, sale más caro que el tiempo que hubiera tomado hacerlo bien.