Cloud vs on-premise: cómo decidir sin sesgo de proveedor

Pocas decisiones de arquitectura tecnológica generan tanto ruido comercial como la elección entre cloud y on-premise. Los hyperscalers tienen equipos comerciales muy bien preparados para vender migración. Los integradores tradicionales tienen un negocio histórico que defender. Y entre medias, el cliente recibe argumentos opuestos sobre la misma realidad.

Esta guía no la firma ningún partner certificado de un hyperscaler ni ningún fabricante de hardware. Está pensada para directivos que quieren entender el marco real de decisión antes de comprometer una inversión que va a condicionar su arquitectura los próximos cinco a diez años.

Plantear la decisión como una elección binaria entre cloud y on-premise es la primera fuente de error. La pregunta útil tiene tres capas: qué cargas de trabajo deben estar en qué sitio, con qué modelo de coste y bajo qué nivel de control operativo.

Una empresa mediana típica tiene entre quince y cuarenta cargas de trabajo distintas: ERP, CRM, correo, colaboración, sistemas de producción, almacenamiento, copias de seguridad, entornos de desarrollo, herramientas de análisis, sistemas industriales. Cada una tiene un perfil distinto de uso, criticidad y sensibilidad al coste.

Tratar esas cargas como un bloque único — "vamos al cloud" o "nos quedamos en local" — es la principal causa de proyectos que se desvían de presupuesto y no entregan el valor esperado.

Cargas con uso variable o estacional. Si la demanda fluctúa de forma significativa a lo largo del día, el mes o el año, el modelo de pago por consumo del cloud público es estructuralmente más eficiente que dimensionar infraestructura propia para el pico.

Servicios donde el time-to-market es crítico. Lanzar un nuevo entorno productivo en horas en lugar de semanas tiene un valor real cuando la velocidad de iteración es parte del modelo de negocio.

Funcionalidades difíciles de replicar internamente. Servicios gestionados de bases de datos, capacidades avanzadas de IA, herramientas de análisis a gran escala. Construir y mantener equivalentes en local raramente es eficiente para una empresa mediana.

Continuidad de negocio y recuperación ante desastres. La replicación geográfica nativa del cloud público resuelve un problema que en local exige inversión significativa en CPDs secundarios.

Equipos con experiencia cloud-native. Si el equipo técnico ya domina los servicios y la cultura operativa del cloud, aprovechar esa capacidad es más eficiente que mantener una infraestructura tradicional en paralelo.

Cargas con uso constante y predecible. Si una aplicación funciona 24/7 con un consumo estable y conocido, el coste total a tres o cinco años en on-premise (incluyendo amortización de hardware, energía, espacio y soporte) suele ser inferior al equivalente en cloud público.

Sistemas industriales y OT. Maquinaria de planta, sistemas SCADA, control de procesos. La latencia, la dependencia de conectividad y el ciclo de vida del hardware industrial hacen que el cloud público raramente sea la opción correcta.

Datos sujetos a marcos regulatorios estrictos. Determinados sectores y tipos de información tienen requisitos de localización, soberanía o auditabilidad que limitan o complican el uso de cloud público. No es imposible — pero exige una arquitectura más compleja y un coste mayor del que aparece en la propuesta inicial.

Inversiones recientes en infraestructura. Si se han renovado servidores hace dos años, descartar esa inversión para migrar al cloud raramente tiene un retorno positivo en el corto plazo. La decisión racional suele ser planificar la migración para el ciclo de renovación siguiente.

Casos donde el control físico de los datos es un requisito de cliente. En B2B regulado, algunos clientes finales exigen que sus datos no salgan de infraestructuras controladas directamente por el proveedor.

En la práctica, la mayoría de empresas medianas terminan operando en modelo híbrido — cargas críticas y predecibles en on-premise o cloud privado, cargas variables y servicios modernos en cloud público, conectividad y gestión unificadas.

El error frecuente no es elegir el modelo híbrido. Es llegar a él por el camino caro: migrar primero todo al cloud, descubrir que algunas cargas no encajan económicamente, y replanificar después una vuelta parcial al on-premise. Ese proceso suele costar entre dos y cuatro veces más que haber diseñado la arquitectura híbrida desde el principio.

Diseñar el modelo híbrido bien desde el inicio exige un mapa de cargas honesto y un análisis del coste total a cinco años por cada una de ellas. No es un análisis trivial — pero es notablemente más barato que aprenderlo migrando.

Las propuestas comerciales de cloud suelen presentar el coste como una factura mensual basada en consumo estimado. La realidad operativa incluye varios componentes que rara vez aparecen en esa primera estimación.

Tráfico de salida (egress). Mover datos del cloud hacia fuera tiene un coste por gigabyte. En cargas con mucho tráfico saliente — backups que se replican fuera, integraciones intensivas, descargas de clientes — esta partida puede multiplicar el coste estimado.

Crecimiento orgánico del consumo. Una vez en cloud, el coste tiende a crecer de forma silenciosa: entornos de prueba que nadie apaga, almacenamiento que se acumula, instancias sobredimensionadas que nadie revisa. Sin gobierno de FinOps activo, el sobrecoste real al cabo de dos años suele estar entre el 30% y el 60% sobre el plan inicial.

Coste de personal especializado. Operar correctamente cloud público exige perfiles con conocimiento específico — arquitectos cloud, FinOps, seguridad cloud — que tienen un coste de mercado significativo. Si el equipo actual no tiene esa capacidad, el coste real incluye formación o contratación.

Coste de migración. Mover una carga del on-premise al cloud no es trivial. Una migración bien hecha de un ERP de empresa mediana puede costar entre 50.000€ y 300.000€ según complejidad, incluyendo refactorización, pruebas y gestión del cambio.

Coste de salida (lock-in). Una vez en un hyperscaler concreto, salir tiene un coste técnico y operativo que conviene calcular antes de comprometerse a tres o cinco años en una arquitectura específica.

El argumento de que "el cloud es más seguro" o "el on-premise es más seguro" carece de sentido sin contexto. La seguridad real depende de la configuración, la operación y la madurez del equipo — no del modelo de despliegue.

El cloud público bien configurado ofrece capacidades de seguridad y resiliencia que serían muy costosas de replicar en local. El cloud público mal configurado expone datos sensibles a internet por errores triviales — y la mayoría de incidentes públicos sonados son exactamente eso: configuraciones incorrectas, no fallos del proveedor.

El on-premise bien gestionado puede tener un perímetro de seguridad muy controlado. El on-premise mal gestionado acumula sistemas sin parchear, copias de seguridad sin probar y dependencias críticas sin redundancia.

La pregunta útil no es "qué modelo es más seguro" — es "tenemos las capacidades operativas para gestionar correctamente el modelo que elegimos".

El marco regulatorio europeo se ha endurecido significativamente. NIS2 amplía las obligaciones de ciberseguridad a un número mucho mayor de empresas medianas. DORA fija requisitos específicos para el sector financiero. El AI Act introduce obligaciones para sistemas de IA con clasificación de riesgo. El RGPD sigue exigiendo localización y trazabilidad para determinados tipos de datos.

Esto no significa que el cloud público quede descartado — significa que la elección de proveedor, región y arquitectura debe revisarse con criterio jurídico además de técnico. Hyperscaler europeo, hyperscaler americano con regiones europeas, cloud privado nacional o on-premise: cada opción tiene un perfil de cumplimiento distinto.

Decidir sin tener claros los requisitos regulatorios aplicables es la receta para una migración que después hay que rehacer.

Inventario honesto de cargas. Mapa de todas las aplicaciones y servicios actuales con su perfil de uso, criticidad, dependencias y consumo real. Sin este inventario, cualquier decisión es una apuesta.

Clasificación por arquetipo. Cada carga se clasifica según su patrón de uso (constante, variable, estacional), su sensibilidad de datos, sus requisitos regulatorios y sus dependencias técnicas.

Modelo de coste a cinco años por arquetipo. No basta con comparar la factura mensual del primer año. La comparación útil es coste total a cinco años incluyendo migración, operación, crecimiento esperado y coste de salida.

Análisis de capacidades del equipo. Qué modelo es coherente con las capacidades reales del equipo actual, considerando lo que podría incorporarse de forma realista en doce a dieciocho meses.

Decisión documentada por carga, no por bloque. El resultado correcto es un mapa que indica qué cargas van a qué modelo, con qué horizonte y bajo qué condiciones se reevaluaría la decisión.

Migrar para reducir coste sin haberlo calculado. La promesa comercial de ahorro inmediato raramente se cumple en cargas estables. Migrar buscando ahorro sin un modelo de coste honesto es la causa más frecuente de migraciones que después hay que revertir parcialmente.

Decidir el modelo antes de tener el inventario. Comprometerse con un proveedor antes de saber qué cargas se van a mover es comprar antes de saber qué se necesita.

Subestimar el coste de operación cloud. La factura del proveedor es solo una parte. Sin gobierno activo de coste, sin perfiles especializados y sin disciplina operativa, el modelo se descontrola.

Ignorar el lock-in. Adoptar servicios propietarios muy específicos del proveedor crea dependencias que limitan opciones futuras. No es necesariamente malo — pero debe ser una decisión consciente, no una consecuencia accidental.

Confundir modernización con migración. Mover una aplicación obsoleta al cloud no la moderniza. La hace obsoleta en cloud y, además, más cara de operar. La modernización exige rediseño — no solo cambio de ubicación.

¿Es siempre más barato el cloud? No. En cargas constantes y predecibles, el on-premise puede ser entre un 30% y un 50% más eficiente a cinco años. En cargas variables o estacionales, el cloud suele ser claramente más eficiente. La respuesta correcta depende del perfil de cada carga.

¿Podemos migrar gradualmente? Sí, y de hecho es la única forma sensata de hacerlo en empresa mediana. El error es no tener un plan global previo: migraciones aisladas sin una arquitectura objetivo definida generan desorden y sobrecoste.

¿Qué hacemos con un ERP que el fabricante quiere mover a cloud obligatoriamente? Es una situación cada vez más frecuente. Conviene analizar las implicaciones reales: coste a cinco años, capacidades de personalización, dependencia del fabricante y opciones alternativas. La presión comercial del fabricante no debe sustituir el análisis propio.

¿Multi-cloud reduce el riesgo de lock-in? En teoría sí. En la práctica, multi-cloud bien hecho exige una capacidad operativa muy superior a la de la mayoría de empresas medianas y puede multiplicar el coste de operación. Para la mayor parte de organizaciones, una estrategia híbrida (un hyperscaler + on-premise) es más realista que un multi-cloud activo.

¿Cuánto tiempo lleva tomar la decisión bien? Un análisis serio para una empresa mediana lleva entre cuatro y ocho semanas: inventario, clasificación, modelo de coste, análisis regulatorio y arquitectura objetivo. Es muy poco comparado con el horizonte de cinco años que va a condicionar.