La conversación sobre on-premise vs nube casi siempre empieza mal: alguien pone la factura mensual de la nube al lado de la depreciación del servidor, la nube sale más cara, y la reunión termina. El problema no es la conclusión — es que la comparación dejó fuera la mitad de los números y la totalidad del riesgo.
Esta guía ordena la decisión con lenguaje de negocio: qué costos no aparecen en el balance del modelo propio, por qué el eje real de la decisión es el riesgo y no el gasto, y en qué casos mantener servidores propios sigue siendo la respuesta correcta.
Lo que el balance no muestra del modelo propio
El costo de un servidor propio no termina en la factura de compra. La operación completa incluye partidas que suelen vivir en otros centros de costo y por eso nunca entran a la comparación:
- Renovación de hardware. El equipo tiene vida útil. Cada tres a cinco años vuelve el mismo desembolso, y la decisión de postergarlo se paga en fallas y en soporte extendido.
- Espacio, energía y refrigeración. El centro de datos —propio o contratado— consume metros, electricidad y climatización todos los días del año, opere la carga al 10% o al 90%.
- Licenciamiento. Sistemas operativos, bases de datos, virtualización y respaldo se licencian por capacidad instalada, no por capacidad usada. Comprar servidores más grandes multiplica esa factura aunque la carga no crezca.
- Personal y guardia. Alguien tiene que parchar, respaldar, monitorear y responder de madrugada. Ese costo existe aunque no esté etiquetado como infraestructura.
- Capacidad ociosa comprada por el pico. Esta es la partida más grande y la menos visible. La infraestructura propia se dimensiona para el peor momento del año — la campaña, el cierre contable, el día de pago — y esa capacidad se paga el resto del año, cuando nadie la usa.
Ninguna de estas partidas desaparece en la nube por arte de magia: se transforman en consumo variable y en trabajo de optimización continua, que es precisamente el objeto de la disciplina FinOps. La diferencia está en que se pagan cuando se usan y se pueden bajar cuando dejan de necesitarse.
Si quieres poner cifras propias sobre esta comparación, nuestra calculadora de TCO construye una estimación con tu inventario en pocos minutos.
El eje real de la decisión es el riesgo
Aun cuando los costos empaten, los dos modelos no dejan a la organización en el mismo lugar. Cuatro riesgos separan un modelo del otro, y son los que un director debería tener sobre la mesa:
Obsolescencia. En el modelo propio, la tecnología que se compra hoy es la que se tendrá durante todo el ciclo de vida del equipo. En la nube, la plataforma se renueva por debajo sin evento de inversión: procesadores nuevos, servicios gestionados nuevos, capacidades de datos e inteligencia artificial que aparecen disponibles sin comprar nada.
Continuidad. La pregunta honesta no es si el centro de datos puede fallar, sino cuánto tarda la operación en volver cuando falle. En infraestructura propia, un sitio alterno real es una segunda inversión completa que muchas organizaciones postergan indefinidamente. En la nube, la redundancia entre zonas de disponibilidad y entre regiones es una decisión de arquitectura, no una compra de hardware.
Velocidad. Una iniciativa que necesita capacidad nueva en el modelo propio arranca con una compra: cotización, aprobación, entrega, instalación. Semanas o meses antes de escribir la primera línea. En la nube el mismo paso son minutos, y el proyecto que no funciona se apaga sin dejar activos varados.
Concentración de conocimiento. Cuando la operación depende de tres personas que saben cómo está armado todo, el riesgo no es técnico sino organizacional. Los servicios gestionados y la infraestructura como código reducen esa dependencia porque la configuración queda escrita, versionada y auditable.
Este es el reencuadre que proponemos a nuestros clientes: el on-premise no es la opción conservadora, es la opción que concentra el riesgo en el balance de la empresa.
On-premise, nube e híbrido en ocho dimensiones
| Dimensión | On-premise | Nube pública | Modelo híbrido |
|---|---|---|---|
| Modelo de gasto | Inversión de capital por adelantado | Consumo variable por uso | Mixto, según carga |
| Elasticidad | Fija hasta la próxima compra | Sube y baja en minutos | Elástica solo en la parte de nube |
| Tiempo para capacidad nueva | Semanas o meses | Minutos | Depende de dónde caiga la carga |
| Renovación tecnológica | Ciclo de inversión recurrente | Continua, a cargo del proveedor | Doble ritmo a coordinar |
| Recuperación ante desastre | Requiere un segundo sitio propio | Zonas y regiones disponibles por diseño | Puede usar la nube como sitio alterno |
| Responsabilidad operativa | Íntegramente del equipo interno | Compartida con el proveedor | Compartida y más compleja de gobernar |
| Control físico del dato | Máximo | Alto, con controles y residencia por región | Selectivo por carga |
| Complejidad de gobierno | Baja, un solo entorno | Media, requiere disciplina de costos | Alta, dos planos que operar como uno |
La columna híbrida merece una lectura cuidadosa: gana flexibilidad, pero paga en complejidad de gobierno. Funciona bien cuando es un modelo híbrido diseñado y no el residuo de una migración inconclusa.
Cuándo mantener servidores propios es la decisión correcta
Hay casos en los que el modelo propio gana con argumentos, no por inercia:
- Latencia junto al proceso físico. Una línea de producción, un control industrial o un equipo médico que necesita respuesta en milisegundos se sirve mejor con cómputo en el sitio. Es el territorio natural del cómputo en el borde.
- Una norma explícita sobre la ubicación del dato. Cuando una regulación sectorial obliga a que cierta información permanezca en una ubicación determinada, la conversación se resuelve con el texto de la norma en la mano. Vale la pena revisarlo: en varios casos la exigencia real es de control y trazabilidad, no de ubicación física, y eso sí se cubre en la nube.
- Equipo reciente con carga plana. Si la infraestructura se renovó hace poco, la carga es estable y predecible y no hay iniciativas nuevas esperando capacidad, el retorno de esa inversión todavía está corriendo. Lo sensato es planificar la transición para el próximo ciclo de renovación, no forzarla ahora.
Fuera de estos casos, mantener el modelo propio suele responder a una razón distinta: nadie ha hecho el ejercicio de comparar con datos.
Cómo se decide sin adivinar
La decisión no se toma para toda la organización de una vez. Se toma carga por carga, y sigue un orden que ya está probado:
- Inventario real. Qué aplicaciones existen, qué consumo tienen de verdad, quién las usa y qué dependencias tienen entre sí.
- Tolerancia a la interrupción. Cuánto puede estar caída cada aplicación y cuánta información puede perderse. Esto define la arquitectura, y la arquitectura define el costo.
- Ataduras al sitio. Qué carga está realmente atada a la ubicación actual por latencia, norma o integración con un equipo físico.
- Costo total de propiedad de ambos escenarios. Con las partidas completas del modelo propio, no solo la depreciación.
- Clasificación por destino y orden de ejecución. Qué se mueve primero, qué se moderniza al moverse, qué se queda y hasta cuándo.
Este es exactamente el trabajo de la fase Assess de la metodología AWS MAP, y es lo que convierte una discusión de opiniones en un plan con responsables y fechas.
Cómo lo abordamos en Caleidos
Acompañamos esta decisión desde la estrategia cloud —inventario, caso de negocio y hoja de ruta— y la ejecutamos con la metodología AWS MAP en sus tres fases. Cuando la respuesta correcta es que una parte se queda en sitio, lo decimos y diseñamos el modelo híbrido para que se opere como una sola plataforma. La facturación de los servicios AWS se maneja en dólares y la optimización del consumo se trabaja de forma continua, no una sola vez al cierre del proyecto.
Si aún estás ordenando los conceptos base, la guía qué es la nube explica los modelos de servicio y de despliegue en lenguaje de negocio.
Preguntas frecuentes
¿Es la nube más barata que el on-premise? Depende de la carga. En cargas variables y proyectos nuevos la nube suele ganar con holgura; en cargas planas sobre equipo amortizado la diferencia se estrecha. La comparación válida usa el costo total de propiedad de ambos modelos, no la factura contra la depreciación.
¿Cuál es la diferencia real? Dónde corre la infraestructura es lo visible. Lo que importa es cómo se comporta el riesgo: obsolescencia, continuidad, velocidad y concentración de conocimiento.
¿Cuándo conviene quedarse en on-premise? Latencia junto al proceso físico, una norma explícita sobre la ubicación del dato, o equipo reciente con carga estable cuyo retorno todavía está corriendo.
¿Por dónde empieza la decisión? Por el inventario y la tolerancia a la interrupción de cada carga. Sin eso, cualquier número es una opinión.
¿Quieres comparar los dos modelos con tus propios números?
Conversemos sobre tu caso: en 30 minutos ordenamos tu inventario, identificamos qué cargas están listas para moverse y cuáles conviene mantener donde están, y te devolvemos una lectura concreta del costo y del riesgo de cada camino.
