Nube o local, lo que cuenta desde el punto de vista empresarial
7 Min. de lectura
El debate entre cloud y on-prem lleva quince años desarrollándose en dos capas. En la superior, los arquitectos hablan de latencia, escalabilidad y microservicios. En la inferior, la dirección calcula en silencio por qué la factura de AWS en el tercer año supera en un 30 % el business case. En 2026, la capa superior desaparecerá de la mayoría de las decisiones de las pymes. Lo que quedará será una cuestión de TCO con tres o cuatro variables calculadas con honestidad.
Lo más importante en resumen
- Cloud vs. on-prem es una decisión de curvas de costes, no de stack: Quien reduzca la pregunta a contenedores, Kubernetes o VM no se la ha planteado en serio. Las líneas divisorias fiables están en los costes de adquisición, personal, crecimiento y regulación, no en la arquitectura.
- El margen de la nube desaparece con cargas de trabajo predecibles: AWS, Azure y GCP son superiores en precio mientras la carga sea impredecible o muy variable. Con cargas de trabajo estables de pymes, la ventaja se inclina en muchos casos entre el mes 24 y el mes 36 a favor de on-prem o colocation.
- NIS2 y DORA desplazan la decisión, pero rara vez como todos suponen: El cumplimiento normativo no empuja necesariamente a las pymes a la nube. En sectores regulados, on-prem volverá a ser la opción por defecto en 2026, porque la residencia de datos y la auditabilidad neutralizan los argumentos de los hyperscalers.
Relacionado:Las fusiones y adquisiciones rara vez fracasan por el precio / Migración a S/4HANA: antes de la decisión
La cuestión cloud-on-prem es una cuestión de TCO, no de arquitectura
Quien forme parte de las direcciones de pymes y haya decidido una migración a la nube en los últimos doce meses conoce el patrón. El business case inicial calcula un ahorro de dos dígitos a 24 meses. En el plazo de 36 meses, solo queda un porcentaje de un dígito, a menudo con signo contrario. Los descuentos de los hyperscalers se reducen, las tarifas de salida se hacen visibles y el stack de herramientas se multiplica.
El error más común en estos cálculos es asumir que la variable cloud incluye también la variable de personal. No es así. Un entorno cloud moderno requiere ingenieros cloud, responsables de FinOps y especialistas en seguridad, que en la región DACH en 2026 costarán entre 95.000 y 140.000 euros brutos anuales. Quien históricamente tenía dos administradores de sistemas en entornos on-prem, rara vez necesitará menos de cuatro personas en el modelo cloud.
Las cuatro curvas de costes que nadie calcula con honestidad
Un cálculo TCO fiable separa cuatro curvas que en los casos de negocio estándar suelen fundirse en una sola. Esta mezcla es la principal razón por la que las decisiones de migración acaban descubriéndose como errores de cálculo.
- Costes de adquisición. On-premise se presentan como un bloque, mientras que la nube los distribuye a lo largo del ciclo de vida. Quien tiene restricciones de Capex (covenants bancarios, presión sobre el presupuesto de inversión) prefiere estructuralmente la nube, independientemente de la pila tecnológica.
- Costes de personal. La nube no reduce la carga de trabajo de los administradores de sistemas, sino que la desplaza hacia roles especializados con un precio de mercado más alto. Un equipo de tres personas on-premise cuesta menos que un ingeniero de nube más otro de backup y un responsable de FinOps.
- Costes de crecimiento. Ante una carga muy impredecible (estacionalidad, lanzamientos de productos, picos de demanda), la nube es estructuralmente superior. Con una carga estable y planificable, la variante on-premise se vuelve más barera cada año, porque la amortización del hardware supera al OpEx de la nube.
- Costes de salida. La curva menos subestimada. Una migración a la nube es más barata que una salida de ella. Tarifas de egress, esfuerzos de refactorización para servicios propietarios, nuevas negociaciones de licencias: una salida de un entorno AWS de 18 meses cuesta entre 1,5 y 3 veces el esfuerzo de migración. Esto nunca se planifica en el caso de negocio.
Ritmo: por qué la frase «duración de la migración de 18 meses» no significa nada
Los plazos de migración son la cifra más mal utilizada en los debates de nube frente a on-premise. 18 meses de duración de migración pueden significar: 18 meses de implementación técnica con un entorno funcional al final, o 18 meses de operación paralela con costes de doble licencia escalando, más otros 12 meses de estabilización posteriores.
En los proyectos de migración que he observado en pymes de la región DACH, la diferencia rara vez era técnica. Casi siempre residía en el portafolio de aplicaciones. Quien migra entre 40 y 80 aplicaciones SaaS más 15 aplicaciones personalizadas de crecimiento histórico, tiene un calendario muy distinto al de una empresa con tres aplicaciones clave y un ERP.
La cifra honesta no es la duración de la migración, sino el horizonte de estabilización. ¿Cuándo funciona el nuevo entorno sin intervención diaria de ingenieros, sin nuevos tickets, sin sorpresas de rendimiento? Quien no incluya esta cifra en su matriz de decisión está comparando peras con manzanas más caras.
Regulación 2026: NIS2 y DORA desplazan la decisión
Los argumentos de los hiperscalares de los últimos años eran seguridad, cumplimiento normativo y capacidad de auditoría. En tres sectores, este argumento se resquebraja en 2026: banca, infraestructuras críticas y sanidad.
NIS2 exige control demostrable de la cadena de suministro y auditorías de acceso. DORA requiere, en instituciones financieras, pruebas de penetración basadas en amenazas y pruebas de recuperación reproducibles. Todo ello es más difícil en el modelo de hiperscalar que en entornos on-premise con una cadena de propiedad claramente documentada. No porque la nube sea menos segura, sino porque la carga de auditoría se distribuye de forma distinta.
Las pruebas de estrés de DORA que los bancos alemanes están suspendiendo ahora son un indicador temprano. Quien incluye un proveedor de nube como tercer proveedor crítico debe cumplir los requisitos ICT-TPRM, que se han endurecido en 2026. Para muchas pymes bancarias, el retorno a on-premise no es un reflejo anti-nube, sino una racionalidad impulsada por el cumplimiento normativo.
Tres preguntas que los directivos deben responder antes de tomar la decisión
Quien aborde con honestidad la cuestión entre cloud y on-premise en 2026 no podrá evitar estas tres preguntas. Son incómodas porque exigen más al departamento financiero que a la propia TI.
- ¿Qué previsibilidad tiene mi carga de trabajo en los próximos 36 meses? Quien tenga un 80 % de capacidad de predicción debería calcular seriamente on-premise o colocation. Quien tenga un 50 % o menos estará estructuralmente mejor atendido con la nube, ya que la velocidad de adaptación justifica el sobrecoste.
- ¿Qué obligaciones regulatorias me esperan en 2027 y 2028? Quien esté sujeto al CRA, NIS2, DORA o normativas sectoriales debería calcular explícitamente los costes de cumplimiento en ambos modelos. En sectores regulados, la prima de la nube en 2026 dejará de ser financiable para muchas pymes, porque la capacidad de auditoría resultará más cara que la ventaja de los hyperscalers en escalabilidad.
- ¿Cuánto me costará salir del modelo elegido tras 24 meses si este fracasa? Quien no pueda responder a esta pregunta no ha terminado de reflexionar sobre la decisión. Tanto las salidas de la nube como los desmantelamientos on-premise son costosos. Quien analice la cláusula de salida en el business case tomará una decisión distinta a quien solo calcule el camino de entrada.
En las reuniones de dirección en las que estas tres preguntas se respondieron con honestidad, el supuesto de «cloud-first» se revocó con sorprendente frecuencia. No hacia decisiones anti-nube, sino hacia configuraciones híbridas más diferenciadas, con perfiles de carga de trabajo claramente separados.
Preguntas frecuentes
¿Siguen siendo justificables desde el punto de vista económico los entornos puramente on-premise en 2026?
Sí, para pymes con cargas de trabajo estables y predecibles y personal de administración de sistemas disponible. El cálculo del TCO se inclina a favor de on-premise entre el mes 24 y el 36, cuando expiran los descuentos en la nube y la curva de costes de personal se dispara. El rechazo a la nube rara vez es el detonante, sino un cálculo frío.
¿Cuándo es el modelo híbrido la opción correcta y cuándo solo un compromiso caro?
El híbrido funciona cuando las cargas de trabajo se separan claramente según su perfil: aplicaciones nucleares estables en on-premise y picos o cargas estacionales en la nube. El híbrido fracasa cuando surge como un compromiso político entre directivos partidarios de «cloud-first» y escépticos de on-premise. En ese caso, duplica la complejidad sin ventaja en la carga y resulta más caro que cualquiera de las dos opciones puras.
¿Cuánto cuestan los costes de salida de un entorno típico de AWS tras 18 meses?
Realistamente, entre 1,5 y 3 veces el coste original de la migración. Los principales conceptos son las tarifas de egreso, los costes de refactorización para servicios propietarios (Lambda, DynamoDB, SQS) y la renegociación de licencias para software cuya licencia en la nube no es transferible a on-premise. Las pymes subestiman casi siempre este aspecto.
¿Realmente NIS2 hará que las pymes abandonen la nube y vuelvan a on-premise?
En sectores regulados, sí; en no regulados, apenas. Bancos, proveedores de salud y operadores de infraestructuras críticas recalculan en 2026 la carga de auditoría de forma distinta a como lo hacían en 2022, porque NIS2 y normativas sectoriales específicas endurecen las obligaciones en la cadena de suministro. Para las pymes no reguladas, la nube sigue siendo generalmente la opción más eficiente.
¿Se puede delegar la decisión entre cloud y on-premise o debe tomarse a nivel de dirección?
Es una decisión de la alta dirección. La TI puede evaluar arquitecturas y stacks. Pero las curvas de costes a 36 meses, las implicaciones regulatorias y los riesgos de salida corresponden a la dirección general. Quien la delegue en la TI obtendrá una decisión técnica en lugar de una decisión de negocio. Este es el error estructural más frecuente en estos proyectos.
Más lecturas
- Migración a S/4HANA: las pymes tienen que decidir antes de 2026
- IA en contabilidad: el 78 % de las operaciones son oscuras en las pymes
- Los test de estrés DORA que los bancos alemanes no están superando
Más del MBF Media Netzwerk
Fuente de la imagen de portada: Pexels
