La migración de on-premise a la nube es el proceso de mover tus aplicaciones, datos e infraestructura fuera de un centro de datos que tú eres dueño y hacia una plataforma cloud como AWS, Azure o GCP. Corre en fases — descubrir, evaluar, planear, migrar, hacer el cutover y optimizar — y normalmente se hace en olas en lugar de un riesgoso movimiento big-bang.
La parte difícil no es levantar recursos en la nube. Es hacerlo sin romper lo que ya funciona — manteniendo los datos íntegros, el downtime casi en cero y la factura bajo control después de aterrizar. Este checklist es el plan del operador para exactamente eso.
- Descubrir — inventaría cada workload, mapea dependencias y captura líneas base y restricciones de cumplimiento.
- Evaluar — asigna una de las 6 R a cada workload durante la fase de evaluación.
- Planear — elige la plataforma destino, construye la landing zone y agrupa workloads en olas.
- Migrar y hacer el cutover — replica datos de forma continua, prueba en paralelo, cambia en una ventana de bajo tráfico con el rollback listo.
- Optimizar y operar — FinOps, observabilidad y SRE para que las facturas de la nube y la confiabilidad se mantengan bajo control.
El checklist de migración a la nube empieza con el descubrimiento
No puedes migrar lo que no ves. Toda migración exitosa de on premise a la nube empieza con un inventario honesto de la propiedad:
- Cataloga cada workload — aplicaciones, bases de datos, trabajos batch, herramientas internas y el servidor olvidado que nadie admite ser dueño.
- Mapea dependencias — qué habla con qué. Las integraciones ocultas son la causa #1 de sorpresas en la migración.
- Mide líneas base — CPU, memoria, almacenamiento y tráfico actuales, para poder dimensionar correctamente en la nube en lugar de copiar hardware sobredimensionado.
- Marca cumplimiento y residencia de datos — HIPAA, SOC 2, PCI y dónde se permite legalmente que vivan los datos.
- Define métricas de éxito — costo, rendimiento y el presupuesto de downtime objetivos que tienes permitido para cada app.
Salta esto y migras a ciegas. La fase de descubrimiento es donde se escribe el plan real.
Evalúa cada workload: las 6 R
Una vez que puedes ver la propiedad, decides cómo mover cada pieza. El estándar de la industria son las 6 R — asigna exactamente una a cada workload:
| Estrategia | Qué significa | Ideal para |
|---|---|---|
| Rehost | Lift-and-shift tal cual | Salida rápida del centro de datos, apps estables |
| Replatform | Levantar y luego remodelar levemente (p. ej. DB gestionada) | Victorias cloud-native rápidas, bajo riesgo |
| Repurchase | Soltar la app, pasar a SaaS | Herramientas commodity (email, CRM, RH) |
| Refactor | Re-arquitectar para la nube | Apps de alto valor que necesitan escala |
| Retain | Dejarlo on-prem por ahora | Sistemas legados o bloqueados por cumplimiento |
| Retire | Dar de baja por completo | Peso muerto que nadie usa |
La mayoría de los portafolios termina siendo una mezcla. Rehost y replatform hacen el trabajo pesado temprano porque te sacan rápido del centro de datos; refactor es donde inviertes después, en los workloads que justifican la ingeniería.
Lift-and-shift vs re-arquitectar
La pregunta recurrente es si rehostar o re-arquitectar. Rehostar es lo más rápido y de menor riesgo — ideal para salir de un contrato de arrendamiento o mover apps estables. Re-arquitectar desbloquea escalado cloud-native y menores costos de operación pero toma tiempo real de ingeniería. El patrón pragmático: rehosta primero para salir, luego re-arquitecta los workloads de alto valor una vez que están seguros en la nube.
Planea la migración: landing zone y olas
Con las estrategias asignadas, construyes la base y secuencias los movimientos:
- Elige la plataforma destino — AWS, Azure o GCP, elegida por ajuste, no por costumbre. Una evaluación neutral de proveedor importa aquí.
- Construye la landing zone — cuentas, redes, IAM, guardrails y logging antes de que llegue cualquier workload.
- Agrupa workloads en olas — empieza con apps de bajo riesgo y baja dependencia para probar el pipeline, luego escala.
- Configura CI/CD e infraestructura como código — para que los entornos sean repetibles, no hechos a mano e irreproducibles.
Las olas importan porque te dejan entregar valor y aprender temprano en lugar de apostar toda la propiedad en un solo fin de semana de cutover.
Migra y haz el cutover sin downtime
Este es el momento que todos temen, y es controlable con un checklist. La migración de datos a la nube es la parte más riesgosa — mover bases de datos en vivo sin perder una fila ni una transacción — así que tiene su propia disciplina:
- Replica datos de forma continua antes del cutover para que la copia en la nube esté al día. La replicación continua de bases de datos (AWS DMS, Azure Database Migration Service o log shipping nativo) es lo que hace posible una migración de datos a la nube de bajo downtime.
- Corre ambos entornos en paralelo — prueba el workload en la nube mientras on-prem aún atiende tráfico real.
- Valida funcionalidad, rendimiento e integraciones contra tus líneas base antes de cambiar.
- Haz el cutover en una ventana de bajo tráfico usando cambio por DNS o load-balancer para una transición de minutos, no horas.
- Mantén una ruta de rollback probada — el cutover solo es seguro si puedes revertirlo.
La replicación continua más las pruebas en paralelo es lo que mantiene la mayoría de los cutovers en minutos de downtime en lugar de una caída.
Después de aterrizar: optimiza y opera
La migración no termina cuando el tráfico se mueve — ahí es cuando las facturas de la nube tienden a dispararse. La fase final y continua:
- FinOps — dimensiona correctamente las instancias, mata recursos ociosos y agrega alertas de costo para que la factura no te sorprenda.
- Observabilidad — monitoreo, logging y alertas afinados para la nube.
- SRE y automatización — hornea la confiabilidad y el parcheo en pipelines en lugar de tickets.
Una migración sin esta última fase solo mueve tu centro de datos al edificio de alguien más a un precio más alto. Este es el trabajo que nuestro equipo de servicios de migración a la nube integra en cada movimiento — migración, DevOps y FinOps como un solo compromiso, operado por ingenieros nearshore senior en tu zona horaria desde Monterrey con tarifa plana. A diferencia de una casa offshore en India o Dubái, el cutover ocurre durante tu horario de negocio, no a través de una brecha de doce horas — y tú eres dueño de las cuentas de la nube y la IP desde el primer commit.
En resumen
Una migración limpia de on-premise a la nube es una secuencia, no un salto: descubrir, evaluar con las 6 R, construir una landing zone, migrar en olas, hacer el cutover con un plan de rollback, luego optimizar. Rehosta para salir rápido del centro de datos, re-arquitecta los workloads que lo ameritan y trata FinOps como parte del proyecto — no como una idea de último momento. Córrelo en ese orden y te mueves fuera del on-prem sin romper lo que funciona.
