Una migración a la nube en Chile debe comenzar con una pregunta concreta: ¿qué operación necesita mejorar y cómo se comprobará el resultado? Mover un servidor sin revisar dependencias, costos y recuperación puede trasladar los mismos problemas a una factura distinta.
Esta guía propone una checklist para equipos de TI y responsables de negocio que preparan la migración de una aplicación empresarial. Sirve para ordenar la evaluación y decidir si una carga está lista para pasar a producción. Los ejemplos son ilustrativos; cada arquitectura exige pruebas propias.
1. Define el alcance y el resultado esperado
Elige una aplicación y nombra a su responsable de negocio. Describe qué debe mejorar: tiempo de respuesta, capacidad en horas punta, facilidad de mantenimiento o recuperación ante fallas. Registra una medición inicial y un criterio de aceptación que pueda verificarse después.
Antes de avanzar: deja por escrito qué se migra, qué permanece en el entorno actual, quién aprueba el cambio y qué evidencia demostrará que funcionó. “La máquina encendió” no basta: una persona del área usuaria debe completar el flujo de trabajo que necesita.
2. Levanta dependencias, datos y uso real
El inventario debe incluir la aplicación, base de datos, versiones, licencias, almacenamiento, tareas programadas e integraciones. Identifica también directorios de usuarios, correo transaccional, certificados, nombres DNS y servicios externos. Una dependencia olvidada puede interrumpir un proceso aunque el sistema principal esté disponible.
Mide consumo de CPU, memoria, disco y red durante un ciclo representativo del negocio. Considera cierres de mes y otras cargas estacionales. Para una empresa con oficinas o sucursales en Chile, prueba la conectividad desde esas ubicaciones: la experiencia real depende del recorrido completo entre usuario, aplicación y datos.
Entregable: un mapa de dependencias, responsables y requisitos. Separa los datos que se pueden usar en pruebas de aquellos que requieren protección adicional; evita copiar información productiva sin controles definidos.
3. Compara el costo completo, con supuestos visibles
Arma escenarios de uso habitual y de alta demanda. Incluye cómputo, almacenamiento, operaciones de disco, transferencia de datos, respaldos, monitoreo, licencias y soporte. Suma el trabajo de migración y el período en que coexistirán ambos entornos.
Si la facturación está en una moneda distinta de tu presupuesto, registra la moneda y el tipo de cambio usado en la comparación. Define quién revisará el consumo y qué alerta permitirá detectar desviaciones. No asumas un porcentaje de ahorro antes de medir.
Las herramientas de estimación ayudan a comparar escenarios, pero sus supuestos deben revisarse. La documentación de estimación de costos de Google Cloud explica cómo construir y ajustar una evaluación inicial.
4. Prepara accesos, red y monitoreo antes de migrar
Separa producción de pruebas, asigna permisos según funciones y protege las cuentas administrativas con autenticación multifactor. Define cómo se administran secretos, qué conexiones están permitidas y dónde se registrarán los eventos relevantes. Cada alerta debe tener un responsable y un canal de atención.
Una base cloud bien preparada reúne decisiones de identidad, conectividad, seguridad y gobierno. El enfoque de landing zones de Microsoft ofrece una referencia para organizar esos controles antes de desplegar las aplicaciones. La implementación concreta debe ajustarse al tamaño y las necesidades del proyecto.
Antes de avanzar: verifica accesos con cuentas de prueba, confirma que los registros llegan a su destino y comprueba que una alerta de ensayo alcanza al equipo correcto. Revisa también dónde se almacenan datos y copias de seguridad según los requisitos de tu organización.
5. Prueba la recuperación, no solo el respaldo
Acuerda dos objetivos con el negocio: RTO, el tiempo objetivo para restablecer el servicio, y RPO, la pérdida de datos tolerable expresada como tiempo. Son objetivos de diseño que se deben validar, no garantías automáticas del proveedor.
Restaura una copia en un entorno controlado. Mide cuánto demora, comprueba la integridad de los datos y ejecuta un flujo funcional. Conserva el registro de la prueba y de cualquier dependencia necesaria para recuperar el servicio.
El pilar de confiabilidad de AWS recomienda definir la recuperación a partir de las necesidades del negocio y probar su implementación. Si el ensayo no cumple los objetivos, ajusta el diseño antes del cambio productivo.
6. Ejecuta un piloto y decide con evidencia
Usa una carga acotada o un entorno de pruebas representativo. Evalúa funciones críticas, permisos, integraciones, rendimiento y consumo. El piloto debe tener criterios de éxito y una lista de problemas que impiden seguir.
Ejemplo ilustrativo: para una aplicación de inventario, comprueba ingreso de productos, actualización de stock, consulta desde una sucursal y sincronización con el sistema administrativo. Compara los resultados con la línea base; no uses solo la velocidad de la página inicial como señal de éxito.
7. Escribe el plan de cambio y de reversa
Define la ventana del cambio, el orden de las tareas, responsables y puntos de control. Confirma cómo se sincronizarán los últimos datos y cuándo se habilitarán las escrituras en destino.
La reversa necesita un criterio de activación, una persona que decida y un procedimiento probado. Si el entorno nuevo ya recibió transacciones, volver al anterior exige resolver qué ocurrirá con esos datos. La guía de cambio y rollback de AWS aborda expresamente esa diferencia.
Control clave: no retires el entorno de origen hasta validar la operación y cumplir el período de retención acordado. Define también quién autoriza su retiro para evitar costos duplicados indefinidos.
Checklist final: ¿la aplicación está lista?
Antes de aprobar el paso a producción, pide evidencia de estos siete puntos: alcance y responsable; inventario de dependencias; presupuesto con supuestos; accesos y monitoreo probados; restauración validada; piloto aceptado; plan de cambio y reversa ensayado. Para cada punto, registra responsable, estado y enlace al documento o resultado de la prueba.
Si falta una evidencia crítica, deja la decisión pendiente y asigna una acción concreta. Una fecha de migración debe apoyarse en la preparación real del sistema y de las personas que lo operarán.
Cómo llevar esta checklist a tu proyecto
Empieza por una aplicación y reúne a negocio, TI y seguridad en la misma evaluación. Con ese alcance será más fácil comparar alternativas y definir qué necesita el proyecto antes de cotizar o ejecutar.
Puedes conocer el enfoque de servicios cloud de NOVVOR Chile, revisar nuestros servicios de ciberseguridad aplicada o contactarnos para conversar sobre tu proyecto.
Publicado el 5 de octubre de 2026. Guía técnica general: no reemplaza una evaluación de arquitectura, seguridad ni requisitos específicos de la organización.
