"Vamos a poner todo en AWS" sonaba en 2018 como la decisión obvia. En 2026 hay empresas pagando US$ 12.000/mes por una infraestructura que en un rack propio costaría US$ 3.000/año en hardware amortizado más US$ 200/mes en electricidad y mantenimiento. Y al revés: hay empresas con servidores físicos que se les caen una vez al mes porque no hay redundancia ni personal de turno, cuando una migración bien planeada a cloud lo resolvería por una fracción del costo total.
No hay respuesta única. Hay criterios — y este artículo es sobre cuáles.
Qué significa cada cosa
On-premise
Servidores físicos en tu oficina o data center alquilado (colocation). Tú compras, instalas, mantienes y reemplazas el hardware. Tú pagas la electricidad, el aire acondicionado, la conectividad y al técnico que lo cuida.
Cloud (IaaS / PaaS / SaaS)
Alquilas infraestructura virtualizada en data centers de terceros (AWS, Azure, Google Cloud, DigitalOcean, Hetzner, Vultr). Pagas por uso mensual; el proveedor se encarga del hardware. Va desde "una máquina virtual con CPU/RAM/disco" (IaaS) hasta "un servicio completo de base de datos administrada" (PaaS) o "un software 100% administrado" como Microsoft 365, Salesforce, etc. (SaaS).
Híbrido
Mezcla de los dos — datos sensibles o cargas pesadas en local, frontends y picos en cloud. Conectados por VPN o líneas dedicadas.
CAPEX vs OPEX: lo más importante para una pyme
On-premise es CAPEX (gasto de capital): pagas mucho una vez y amortizas a 3–5 años. Cloud es OPEX (gasto operativo): pagas mes a mes mientras lo usas.
Esto no es solo una diferencia contable. Tiene implicaciones reales:
- On-premise deja que pequeños incrementos de uso no aumenten el costo (ya pagaste el hardware). Pero te ata: si necesitas el doble de capacidad mañana, no la tienes.
- Cloud escala linealmente con el uso. Bueno cuando creces; malo cuando descubres que ese pico que tenías 2 horas al mes te factura por las 730 horas.
- El cliente promedio NO necesita escalabilidad elástica. Una pyme con 30 empleados que usa el mismo CRM todos los días no se beneficia de "elasticidad" — paga la fija con el modelo OPEX y suma el riesgo de que el proveedor suba precios.
Comparativa lado a lado
| Criterio | On-premise | Cloud |
|---|---|---|
| Modelo de costo | CAPEX (compra inicial alta, después bajo) | OPEX (mensual recurrente) |
| Tiempo de provisión | Días o semanas | Minutos |
| Escalabilidad | Limitada por hardware comprado | Prácticamente ilimitada |
| Mantenimiento físico | Tuyo | Del proveedor |
| Control sobre datos | Total | Compartido (depende del contrato) |
| Latencia para usuarios locales | Muy baja | Variable (mejor en regiones cercanas) |
| Disponibilidad | Depende de tu equipo y energía | SLA 99.9–99.99% típicamente |
| Recuperación ante desastres | Requiere infraestructura adicional | Más simple (regiones, snapshots) |
| Compliance datos personales (Colombia) | Más simple cuando data se queda local | Requiere análisis (transferencia internacional Ley 1581) |
| Lock-in | Mínimo (hardware estándar) | Alto (formatos y servicios propietarios) |
| Costo a 5 años (carga estable) | Generalmente menor | Generalmente mayor |
| Costo a 5 años (carga variable) | Generalmente mayor | Generalmente menor |
| Personal técnico requerido | Más (admin de sistemas) | Menos (devops / cloud engineer) |
Casos donde gana on-premise
1. Cargas pesadas y constantes
Una empresa de diseño con renders 24/7, un servidor de archivos de 50 TB que se accede todo el día, una base de datos transaccional de alto volumen — en estos casos, el cálculo a 3–5 años suele dar más barato comprar el hardware que pagarlo en cloud.
2. Datos altamente sensibles o regulados
Información de pacientes (sector salud), datos financieros bajo regulación específica, propiedad intelectual estratégica. Cuando la ley te exige tener el dato en territorio colombiano o el riesgo reputacional de una fuga es altísimo, mantenerlo local con controles estrictos es más simple que negociar cláusulas con un hyperscaler.
3. Latencia crítica
Aplicaciones industriales (SCADA, control de planta), CAD/CAM colaborativo, edición de video en tiempo real — la latencia hacia un cloud regional (incluso "São Paulo") puede ser inaceptable. On-premise resuelve la latencia por cercanía física.
4. Cargas predecibles sin pico
Si tu uso de cómputo es plano todo el año, la elasticidad del cloud no te da valor — solo añade costo.
5. Conectividad poco confiable
Plantas de producción en zonas con internet inestable, almacenes en regiones remotas. Si depender del cloud significa que la operación se detiene cuando se cae internet, on-premise es la única opción seria.
Casos donde gana cloud
1. Startups y proyectos nuevos sin tracción aún
No tiene sentido invertir US$ 10.000 en hardware para una idea que no sabes si va a funcionar. Cloud te deja arrancar por US$ 50/mes y crecer cuando el negocio crezca.
2. Picos estacionales o impredecibles
E-commerce con picos de Black Friday, sitios de eventos, herramientas de campaña, procesos de cierre mensual/anual. Pagar la capacidad pico el resto del año en hardware es desperdicio.
3. Equipos distribuidos en múltiples ubicaciones
Si tu equipo está en Cartagena, Medellín y Bogotá accediendo a los mismos sistemas, cloud regional les da latencia razonable a todos sin tener que montar VPN site-to-site complejas.
4. Servicios donde la disponibilidad 99.9%+ es crítica desde el día 1
Replicar redundancia 99.99% on-premise (servidores duplicados, energía redundante, dos ISPs) cuesta una fortuna. Un AWS RDS Multi-AZ te lo da incluido.
5. Software-as-a-Service que no quieres administrar
Microsoft 365 para correo, Google Workspace, Salesforce, HubSpot, GitHub. Montar y mantener equivalentes on-premise es absurdo para una pyme. Esto no es discusión — usa el SaaS.
El gran malentendido del cloud
Mucha gente cree que "cloud es más barato". Es más barato para casos de uso variables o pequeños. Es más caro para cargas grandes y estables. AWS, Azure y Google ganan dinero precisamente porque el precio por unidad de cómputo es bastante mayor que el costo amortizado del mismo cómputo en hardware propio — su margen viene de ahí, además de los servicios administrados.
Hay un patrón claro hoy: empresas que migraron 100% a cloud hace 5 años están "repatriando" cargas pesadas de vuelta a infraestructura propia o colocation. Dropbox lo hizo, 37signals lo hizo público con cifras (ahorró US$ 7M/año). Esto no significa que el cloud sea malo — significa que la decisión "todo a cloud" sin análisis es ingenua.
Arquitectura híbrida: lo que mejor funciona en pymes
El patrón que más recomiendo hoy a pymes colombianas:
- Correo y colaboración: SaaS (Microsoft 365 / Google Workspace).
- Sitio web y servicios públicos: Cloud IaaS o PaaS (Hostinger, DigitalOcean, Vercel para frontends).
- Backup offsite: Cloud storage (Backblaze B2, Wasabi).
- ERP / sistema de gestión: Depende — si es propio y crítico, on-premise local con backup cloud. Si es SaaS de tercero (SAP B1 Cloud, Siigo), cloud directamente.
- Archivos de trabajo diario: NAS on-premise (Synology) sincronizado a cloud.
- Bases de datos pesadas: On-premise con replicación, cloud solo si la latencia lo soporta.
Cómo decidir bien
- Mide tu carga actual real. CPU, RAM, disco, tráfico mensual. No estimes, mide.
- Proyecta a 3 años. Crecimiento estimado, no aspiracional.
- Calcula TCO (Total Cost of Ownership) de ambos escenarios incluyendo: hardware/cloud, electricidad, conectividad, software, licencias, personal técnico, backups.
- Considera riesgos legales (Ley 1581, contratos con clientes que exijan residencia de datos).
- Considera el cost-of-exit: cuánto te costaría salir del cloud si en 2 años decides moverte. Eso es lock-in real.
Para la mayoría de pymes colombianas con 10–80 empleados, el modelo híbrido (correo y backup en cloud + sistema de gestión y archivos on-premise) suele dar el mejor costo total y el mejor control. Pero cada caso se evalúa con números, no con dogmas.
¿Tienes una decisión que tomar?
Si estás evaluando migrar a cloud, repatriar cargas o decidir entre comprar servidores o alquilarlos, cuéntame qué tienes hoy y a dónde quieres llegar y armamos los números para decidir con criterio.