Es un patrón que se repite: una empresa mediana recibe una propuesta de migración total a la nube. El proveedor muestra números de ahorro proyectado, escalabilidad ilimitada y la promesa de cero preocupaciones de mantenimiento. El gerente general aprueba. Dieciocho meses después, la factura mensual triplicó la estimación inicial, el equipo TI no comprende la nueva arquitectura, y cualquier cambio menor en producción requiere un consultor externo.
El problema no era la nube. Era que nadie hizo las preguntas correctas antes de decidir.
El error de partida: tratar esto como una decisión binaria
On-premise versus cloud no es un concurso entre tecnologías. Es un marco de decisión que depende de factores concretos: el perfil de las cargas de trabajo, la capacidad técnica del equipo, los requisitos regulatorios y de cumplimiento, y el modelo de costos real proyectado a 36 meses.
Tratar la decisión como binaria —migrar todo a la nube o no tocar nada— es el primer error. La mayoría de las organizaciones medianas tiene cargas de trabajo de ambos tipos: algunas se sostienen mejor en infraestructura propia, otras tienen ventaja clara en cloud. El criterio de distribución es lo que define una arquitectura sostenible.
Qué factores determinan el lugar de cada carga de trabajo
Las cargas con consumo predecible y constante —servidores de aplicaciones internas, bases de datos transaccionales, sistemas ERP— suelen tener mejor costo total de propiedad en infraestructura propia bien dimensionada. El costo marginal de crecimiento dentro de la capacidad instalada es cercano a cero.
Las cargas con demanda variable, picos estacionales, necesidad de escalar rápido o acceso global tienen ventaja real en cloud. Los servicios de procesamiento batch de alta demanda, los ambientes de desarrollo y pruebas, y los servicios de respaldo remoto son ejemplos donde el modelo de pago por uso tiene sentido económico.
El análisis de cargas debe ser explícito y documentado, no intuitivo. Una empresa que no sabe qué consume cada servicio no puede tomar una decisión de arquitectura con fundamento.
Lo que la nube no resuelve por defecto
El principal malentendido sobre cloud es que simplifica la operación TI. No la simplifica: la transforma. Alguien tiene que gestionar los grupos de seguridad, los permisos de acceso, el monitoreo de costos, las actualizaciones de servicios administrados y las políticas de retención de datos. Si ese alguien no existe en el equipo con la capacitación necesaria, la empresa está pagando por infraestructura que no controla de forma real.
El modelo de pago por uso tiene otro efecto que pocos anticipan en la fase de evaluación: cuando el uso crece, el costo crece de forma proporcional o superior. Las organizaciones que dimensionan bien su infraestructura propia tienen un comportamiento de costos diferente: el crecimiento dentro de la capacidad instalada tiene costo marginal muy bajo.
Esto no es un argumento contra la nube. Es un argumento contra la decisión de migrar sin haber modelado los costos reales con los datos de consumo reales de la organización.
El modelo híbrido como punto de partida realista
Para la mayoría de las empresas medianas en Chile, el escenario técnica y económicamente más robusto no es elegir entre on-premise o cloud: es definir con criterio qué cargas van a cada entorno.
Un esquema que aparece con frecuencia en organizaciones de entre 50 y 300 colaboradores: infraestructura propia para aplicaciones internas críticas, bases de datos y sistemas con alta transaccionalidad; servicios cloud para ambientes de desarrollo, procesamiento variable, almacenamiento de respaldo geográficamente distribuido y servicios de comunicación.
El criterio de distribución debe estar documentado y revisarse con periodicidad. Las condiciones cambian: los precios de los servicios cloud varían, el consumo de la organización evoluciona, y las capacidades del equipo técnico se desarrollan o se reducen.
El riesgo que las propuestas de migración no cubren
Antes de aprobar cualquier decisión de cambio de infraestructura, hay una pregunta que debe tener respuesta: ¿qué pasa con esta carga de trabajo si el proveedor modifica sus condiciones, cambia su modelo de precios o interrumpe el servicio?
Si la respuesta es “no tenemos un plan para ese escenario”, hay un riesgo operacional que la propuesta técnica no está abordando. El vendor lock-in no es solo un concepto teórico: es la situación concreta de no poder migrar sin costos prohibitivos o sin perder funcionalidad crítica.
El criterio que aplica Aleph Server
Antes de recomendar cualquier cambio de arquitectura, mapeamos las cargas de trabajo existentes, analizamos el costo total a tres años en cada escenario y definimos el criterio de distribución entre on-premise y cloud según los factores técnicos y económicos reales de la organización.
No vendemos cloud ni defendemos on-premise como posición de principio. Recomendamos lo que tiene sentido para el tamaño, el equipo y el contexto operacional de cada empresa. Eso incluye, cuando corresponde, recomendar no migrar nada todavía.
