La guía de selección de plataforma cloud no debería empezar por comparar catálogos de servicios. Debería empezar por una pregunta más exigente: ¿qué capacidad debe ganar el negocio y qué restricciones no puede asumir? Una empresa con cargas transaccionales críticas, datos regulados y equipos reducidos no evalúa una plataforma con los mismos criterios que una organización que necesita analizar grandes volúmenes de datos o desplegar productos digitales en varios mercados.
La elección condiciona costes operativos, velocidad de entrega, seguridad, autonomía de los equipos y capacidad de respuesta ante incidencias. También puede consolidar deuda técnica durante años si se toman decisiones basadas únicamente en descuentos iniciales, familiaridad con una marca o funcionalidades aisladas. La plataforma adecuada no es la que ofrece más servicios, sino la que permite operar con fiabilidad y evolucionar sin complejidad innecesaria.
Definir el problema antes de evaluar proveedores
Antes de analizar AWS, Microsoft Azure, Google Cloud u opciones de nube privada e híbrida, conviene documentar el estado actual. El inventario debe identificar aplicaciones, integraciones, bases de datos, dependencias con sistemas heredados, flujos de datos y requisitos de disponibilidad. Sin esta información, es fácil trasladar ineficiencias existentes a una infraestructura nueva y aumentar el coste de operación.
La evaluación debe traducir las prioridades empresariales en requisitos verificables. Por ejemplo, una operación con servicio 24/7 puede exigir recuperación ante desastres con objetivos definidos de tiempo de recuperación y pérdida de datos. Una compañía que procesa información sensible puede necesitar controles de residencia de datos, cifrado gestionado por el cliente, segregación de entornos y trazabilidad detallada. Una empresa en fase de crecimiento puede priorizar automatización, elasticidad y una estructura de costes que no penalice la expansión.
No todos los requisitos tienen el mismo peso. Conviene clasificarlos entre obligatorios, relevantes y deseables. Esta distinción evita que una demostración comercial o una funcionalidad secundaria desplace criterios que afectan directamente a continuidad operativa, cumplimiento o margen económico.
Guía de selección de plataforma cloud: los criterios decisivos
Una decisión sólida combina criterios técnicos, financieros y organizativos. Evaluarlos por separado produce una visión incompleta: una solución técnicamente excelente puede resultar inviable si el equipo no puede operarla, y una opción barata en el primer año puede generar costes crecientes por transferencias de datos, licencias o dependencia de especialistas.
Arquitectura y compatibilidad con las cargas de trabajo
El primer criterio es la adecuación a las aplicaciones reales. Hay que determinar qué cargas pueden modernizarse, cuáles deben reubicarse temporalmente y cuáles requieren una sustitución progresiva. Una aplicación monolítica con dependencias rígidas no obtiene automáticamente beneficios por ejecutarse en contenedores. En ocasiones, una máquina virtual bien gestionada es una decisión más segura mientras se define una modernización gradual.
También importa la madurez de los servicios gestionados necesarios: bases de datos, mensajería, integración, analítica, inteligencia artificial, gestión de identidades y herramientas de observabilidad. La pregunta no es si el proveedor dispone de un servicio, sino si dicho servicio cubre el rendimiento, las políticas de seguridad y el modelo de operación que la empresa necesita.
Las integraciones merecen un análisis específico. Los costes y la latencia asociados a mover datos entre regiones, nubes o centros de datos locales pueden modificar por completo el diseño inicial. Una arquitectura híbrida puede ser razonable por razones regulatorias o de latencia, pero exige una red, una identidad y una monitorización diseñadas de forma coherente.
Seguridad, cumplimiento y control operativo
La seguridad cloud se basa en un modelo de responsabilidad compartida. El proveedor protege la infraestructura subyacente, pero la empresa sigue siendo responsable de configurar accesos, datos, redes, identidades, registros y políticas de uso. Elegir una plataforma sin definir cómo se gobernará multiplica el riesgo de permisos excesivos, recursos expuestos y costes no controlados.
La plataforma debe permitir aplicar el principio de mínimo privilegio, autenticación multifactor, segmentación de red, cifrado en tránsito y en reposo, gestión de secretos y registros centralizados. Además, estos controles deben ser automatizables. Si la seguridad depende de revisiones manuales esporádicas, la consistencia se deteriorará a medida que crezcan los entornos y los equipos.
Para sectores regulados, no basta con revisar certificaciones generales. Hay que validar la ubicación de los datos, los acuerdos de tratamiento, las opciones de auditoría, la retención de registros y la capacidad de demostrar cumplimiento. La certificación del proveedor no sustituye los controles internos ni resuelve una mala configuración.
Coste total, no solo precio de entrada
El coste cloud debe analizarse como coste total de propiedad. Incluye consumo de computación, almacenamiento, redes, transferencias de datos, soporte, herramientas de terceros, licencias, formación, migración y operación continua. Los precios por hora o los créditos promocionales son relevantes, pero no describen el compromiso económico a tres años.
Conviene modelar varios escenarios: consumo estable, crecimiento previsto, picos estacionales y fallo regional. Este último suele omitirse, aunque la alta disponibilidad y la recuperación ante desastres pueden duplicar ciertos componentes. El objetivo no es evitar la resiliencia, sino conocer su coste y decidir qué nivel de protección necesita cada servicio según su impacto de negocio.
FinOps debe formar parte del diseño desde el principio. Etiquetado obligatorio, presupuestos, alertas, cuentas o suscripciones separadas y revisión periódica de recursos inactivos son mecanismos básicos. Las reservas y compromisos de uso pueden reducir el gasto, pero solo deben contratarse cuando exista suficiente evidencia sobre patrones de consumo estables.
Capacidades del equipo y modelo de soporte
La plataforma elegida debe encajar con las capacidades disponibles y con el modelo operativo que la empresa quiere construir. Un amplio catálogo de servicios avanzados aporta valor únicamente si existe conocimiento para diseñarlos, protegerlos y mantenerlos. De lo contrario, puede aumentar la dependencia de proveedores externos y ralentizar las decisiones.
Es recomendable evaluar la experiencia actual del equipo en automatización, infraestructura como código, gestión de identidades, redes, contenedores y respuesta a incidentes. Las carencias no obligan a descartar una plataforma, pero sí deben reflejarse en un plan de formación, contratación o acompañamiento especializado.
El soporte también es una variable operativa. Hay que revisar tiempos de respuesta, cobertura, escalado de incidencias y acceso a perfiles técnicos cualificados. Para sistemas críticos, confiar en soporte estándar sin un procedimiento interno de escalado puede dejar a la organización expuesta durante una interrupción relevante.
Evitar una decisión basada en una prueba aislada
Las pruebas de concepto son útiles cuando validan hipótesis concretas. Una prueba bien planteada puede medir latencia, rendimiento de una base de datos, integración con identidad corporativa, despliegue automatizado o capacidad de recuperación. Una prueba genérica que solo demuestra que una aplicación puede ejecutarse en la nube aporta poca información para una decisión estratégica.
El piloto debe tener criterios de aceptación, datos representativos y responsables claros. También debe incluir aspectos que suelen aparecer tarde: trazabilidad, costes de red, permisos, copias de seguridad, monitorización y despliegue entre entornos. Si estos elementos se ignoran, la prueba puede parecer satisfactoria y fracasar al pasar a producción.
En organizaciones con varios dominios tecnológicos, no siempre es conveniente imponer una única plataforma para todo. Una estrategia multicloud puede responder a adquisiciones, necesidades regulatorias o servicios especializados, pero debe justificarse con beneficios concretos. Gestionar varias nubes implica duplicar controles, habilidades, herramientas y procesos. La diversificación sin una disciplina de arquitectura suele añadir complejidad, no resiliencia.
Convertir la selección en una decisión gobernable
Una matriz de evaluación ponderada ayuda a comparar alternativas con transparencia. Los pesos deben ser acordados por negocio, seguridad, finanzas y tecnología antes de recibir propuestas detalladas. Así se reduce el riesgo de modificar los criterios para favorecer la opción que parece más atractiva al final del proceso.
La decisión no termina con la firma del contrato. Debe acompañarse de una arquitectura de referencia, reglas de gobierno, estándares de infraestructura como código, un modelo de cuentas o suscripciones, políticas de seguridad y métricas de operación. Sin estos fundamentos, incluso una plataforma adecuada acabará fragmentada por decisiones locales.
StrateCode aborda este tipo de decisiones conectando la evaluación de plataforma con la arquitectura objetivo y el plan de implementación. El valor no está en recomendar una marca, sino en establecer una base técnica que permita modernizar con control, medir resultados y mantener opciones abiertas cuando el negocio cambie.
La mejor elección es la que permite al equipo construir, operar y mejorar sistemas críticos con menos incertidumbre. Si la plataforma hace más predecible la entrega, protege mejor los datos y convierte el gasto tecnológico en una decisión gestionable, está cumpliendo su función mucho después de que termine el proceso de selección.
