La mayoría de migraciones cloud no fracasan por tecnología. Fracasan por falta de inventario inicial, expectativas irreales sobre tiempos y ausencia de un plan de rollback documentado. El resultado habitual es un proyecto que se alarga el doble, con costes superiores a lo presupuestado y un equipo agotado de gestionar dos infraestructuras en paralelo.
El primer paso que nadie da bien: el inventario honesto
El primer paso es un inventario honesto: qué sistemas hay, quién los usa, con qué frecuencia y qué pasaría si estuvieran caídos cuatro horas. Sin eso, cualquier plan de migración es ficción. La mayoría de inventarios que vemos tienen entre un 20 y un 40% de sistemas que nadie sabía que estaban en producción hasta que alguien preguntó.
- Listado completo de sistemas con propietario de negocio asignado (no solo técnico)
- Criticidad por ventana de tiempo: qué pasa si está caído 1h, 4h, 24h
- Dependencias entre sistemas: qué aplicación necesita que otra esté disponible primero
- Estado actual: versión, sistema operativo, fecha del último parcheo, si tiene soporte activo
- Frecuencia de uso real: hay sistemas que aparecen críticos en el papel pero se usan mensualmente
Las 6 R y el primer año que siempre cuesta más
La estrategia de las '6 R' (rehost, replatform, refactor, repurchase, retire, retain) sigue siendo la referencia práctica. Para la mayoría de pymes, el 70% de sistemas va a rehost y un 20% a retire. El 10% restante es donde está el trabajo real y la mayoría del presupuesto.
- Rehost (lift and shift): mover el sistema tal cual a cloud. Rápido, barato, sin optimización.
- Replatform: migrar con ajustes menores para aprovechar servicios cloud (base de datos gestionada, etc.).
- Refactor: rediseñar la aplicación para ser cloud-native. Caro, lento, pero con mayor beneficio a largo plazo.
- Repurchase: reemplazar por un SaaS equivalente (pasar de servidor Exchange propio a Microsoft 365).
- Retire: apagar sistemas que ya no se usan. El 20% más sencillo y frecuentemente ignorado.
- Retain: mantener en on-premise por razones técnicas, regulatorias o de coste.
Una migración cloud bien planificada no es un proyecto técnico; es un proyecto de negocio con componente técnica. Las decisiones sobre qué migrar cuándo y a qué ritmo deben tomarse con el contexto de qué puede permitirse el negocio en términos de riesgo operativo y ventana de interrupción.
Si estás planificando una migración cloud o quieres entender qué implica antes de comprometerte, podemos ayudarte a evaluar opciones sin presión comercial.
Ver servicio de transformación digital