Elegir un partner de migración cloud no consiste principalmente en encontrar una empresa que conozca AWS, Azure o GCP. La pregunta difícil es si puede convertir un entorno incompleto en un plan que tu equipo pueda validar, operar y revertir cuando algo falle.
Un partner competente debe ayudar a decidir qué mover, a qué destino, en qué orden y bajo la responsabilidad de quién. Si la propuesta salta directamente a herramientas o a una factura estimada, probablemente todavía oculta decisiones importantes.
Define el problema antes de comparar proveedores
“Migrarnos a cloud” no es alcance suficiente. Empieza haciendo explícita la restricción de negocio:
- termina un contrato de data center o hosting;
- cambian los costes de VMware o de renovación de hardware;
- la plataforma no cumple requisitos de recuperación o escalado;
- la nube actual ya no encaja técnica o comercialmente;
- una adquisición ha dejado entornos duplicados;
- los equipos necesitan una base de delivery más mantenible.
Son proyectos distintos. Una salida con fecha límite puede priorizar reubicar primero. Un problema de fiabilidad puede exigir cambios de arquitectura. Un problema de coste no se resuelve necesariamente copiando el mismo diseño a otro proveedor.
Si el destino sigue abierto, compáralo mediante un assessment de migración cloud. Si Azure ya está decidido, las preguntas pertenecen a un plan específico de migración a Azure.
Pregunta qué produce el discovery
El discovery debe producir evidencia, no una presentación con diagramas genéricos. Pregunta qué se inventariará y qué decisiones existirán al terminar.
Un alcance serio suele cubrir:
- aplicaciones, máquinas virtuales, bases de datos, storage y contenedores;
- integraciones de entrada y salida;
- rutas de red, DNS, identidad, certificados y secretos;
- volumen de datos, consistencia y ventanas de transferencia;
- criticidad, responsables, mantenimiento y compliance;
- backups, recuperación y observabilidad actual;
- licencias, dependencias físicas y software sin soporte.
El resultado útil es un registro de workloads conectado con dependencias y responsables. Sin eso, las oleadas son estimaciones frágiles.
Pide ver la estructura de los entregables. Puede estar anonimizada, pero debería mostrar cómo se registran incógnitas, supuestos, riesgos y decisiones.
Evalúa las decisiones workload por workload
Un partner no debería imponer una sola estrategia. Cada carga puede requerir rehost, replatform, refactor, replace, retire o retain.
La recomendación debe explicar:
- por qué encaja la estrategia;
- qué dependencia o restricción la condiciona;
- qué debe cambiar antes de migrar;
- cómo se probará;
- quién acepta el resultado;
- qué ocurre si falla la aceptación.
Desconfía si todo se convierte en refactor. Modernizar puede aportar valor, pero combinar rediseño, cambio de plataforma y movimiento de datos aumenta los failure modes. En el extremo contrario, reubicar todo puede limitarse a posponer deuda operativa.
Comprueba la neutralidad del destino
Las certificaciones demuestran familiaridad con una plataforma, no que sea el destino correcto para cualquier workload.
Pide comparar:
- compatibilidad de servicios y madurez operativa;
- red y conectividad híbrida;
- identidad y seguridad;
- gravedad de datos y coste de transferencia;
- resiliencia y recuperación;
- capacidades reales del equipo;
- licencias y compromisos contractuales;
- dependencia futura de servicios propietarios.
Una recomendación útil muestra trade-offs. “Azure porque somos partner” o “AWS porque tiene más servicios” no son decisiones de arquitectura.
Examina oleadas, cutover y rollback
El plan debe agrupar dependencias, no ordenar una hoja por nombre de servidor.
Para cada oleada espera:
- criterios de entrada y prerrequisitos;
- sincronización de datos;
- pruebas y criterios de aceptación;
- responsables técnicos y de negocio;
- ventana y comunicaciones;
- secuencia de cutover;
- condiciones de parada y rollback;
- periodo de observación posterior.
Pregunta qué parte del rollback puede probarse antes de producción y en qué momento deja de ser seguro, por ejemplo después de comenzar las escrituras en la nueva base de datos. “Restauraremos el backup” no es un plan completo si no se conocen tiempo de recuperación, pérdida de datos y sistemas dependientes.
Aclara el ownership antes y después
La migración cruza aplicación, infraestructura, seguridad y negocio. La propuesta debe distinguir quién:
- aporta conocimiento de aplicación;
- aprueba la arquitectura destino;
- construye landing zone, red e identidad;
- modifica configuración o código;
- valida el comportamiento de negocio;
- aprueba el cutover;
- asume incidencias durante la estabilización;
- opera el destino tras el handover.
Siempre que sea viable, el trabajo debe realizarse en cuentas y repositorios controlados por tu empresa. Código de infraestructura, runbooks, diagramas, decisiones y evidencias deben seguir accesibles al terminar.
Si nadie ha acordado quién opera el destino, el proyecto está incompleto. Puede hacerlo el equipo interno o un servicio de infraestructura cloud gestionada, pero debe decidirse antes de la semana del handover.
Compara precios a través de los supuestos
El precio depende del número de workloads, arquitectura, datos, dependencias, destino, refactor, tolerancia al downtime, pruebas y compliance. Dos ofertas no son comparables si una incluye discovery, validación de aplicaciones y estabilización y la otra solo construye infraestructura.
Pide separar:
- discovery y planificación;
- fundación del destino;
- ejecución por oleadas;
- cambios de aplicación;
- transferencia de datos y terceros;
- estabilización y handover;
- exclusiones y control de cambios.
Un precio cerrado funciona con alcance estable. Un discovery acotado por tiempo suele ser más honesto si el entorno está mal documentado. La señal de riesgo no es el modelo comercial, sino un precio que no puede trazarse hasta alcance y responsabilidad.
Usa un scorecard práctico
| Área | Evidencia | Señal de riesgo |
|---|---|---|
| Discovery | Registro de workloads, dependencias y responsables | Inventario limitado a VMs o factura cloud |
| Arquitectura | Opciones, trade-offs y decisiones registradas | Destino elegido antes de requisitos |
| Ejecución | Oleadas, criterios, cutover y rollback | Un único movimiento con validación vaga |
| Seguridad | Identidad, secretos, red y compliance | Seguridad pospuesta hasta después |
| Ownership | Matriz de responsabilidad y escalado | “Trabajamos con tu equipo” sin responsables |
| Handover | Código, runbooks, diagramas y sesiones | Conocimiento encerrado en tickets |
| Comercial | Supuestos, exclusiones y cambios | Precio bajo con trabajo de aplicación indefinido |
Pondera el scorecard según la restricción principal. Un entorno regulado necesita más peso en evidencia; una salida de contrato, más peso en secuencia y fechas ejecutables.
Diez preguntas antes de firmar
- ¿Qué información necesitáis antes de recomendar destino?
- ¿Qué entrega el discovery y qué decisiones quedan abiertas?
- ¿Cómo descubrís dependencias no documentadas?
- ¿Cómo seleccionáis la primera oleada?
- ¿Cuáles son los criterios de aceptación y rollback?
- ¿Qué cambios de aplicación están incluidos?
- ¿Quién asume incidencias durante la estabilización?
- ¿Qué podrá operar nuestro equipo sin vosotros?
- ¿Qué supuestos pueden cambiar precio o calendario?
- ¿Cuándo recomendaríais no migrar un workload?
La última pregunta es especialmente útil. Un partner fiable debe poder explicar cuándo mantener, sustituir o retirar una carga es mejor que moverla.
Elige quien haga el riesgo inspeccionable
La mejor propuesta no es necesariamente la que tiene más badges, el plazo más corto o más diapositivas. Es la que hace visibles dependencias, decisiones, responsables, failure modes y supuestos comerciales para que tu equipo pueda cuestionarlos.
Esa visibilidad convierte una empresa de migración cloud en un partner responsable y da al cutover un plan en lugar de una promesa.
