Cloud sí, pero con cabeza
Llevamos cuatro décadas montando infraestructura en empresas de Navarra y, durante los últimos diez años, casi todas las conversaciones empiezan igual: "queremos migrar a la nube". Lo que no siempre está claro es qué se quiere migrar, por qué y a qué precio real. La nube no es siempre mejor, ni siempre más barata, ni siempre más segura. Es, sencillamente, otra forma de comprar y operar TI: con sus ventajas y con sus trampas.
En Niebla Informática hemos visto los dos extremos. Empresas que migraron correo, colaboración y backups a Microsoft 365 y ganaron en agilidad y resiliencia sin discusión. Y empresas que llevaron su ERP completo a un proveedor hyperscaler y, dieciocho meses después, pagaban más que con su servidor anterior, con peor latencia y atadas a un contrato del que no era barato salir. La diferencia entre un caso y otro casi nunca es la tecnología: es la decisión previa.
Este artículo es una guía honesta, sin "todo a la nube" ni "todo en local". Si después de leerlo tienes dudas sobre tu caso concreto, contáctanos: preferimos decir "no migres todavía" antes que vender un proyecto que no te encaja.
Tipos de nube: IaaS, PaaS, SaaS e híbrido
Antes de decidir, conviene saber exactamente de qué hablamos cuando decimos "nube":
- IaaS (Infrastructure as a Service): alquilas máquinas virtuales, almacenamiento y red. Tú instalas el sistema operativo y lo que va encima. Ejemplos: AWS EC2, Azure Virtual Machines, Hetzner Cloud, OVHcloud. Útil cuando quieres mantener tu stack actual pero sin servidor físico.
- PaaS (Platform as a Service): el proveedor te da una plataforma gestionada (base de datos, runtime de aplicación, colas) y tú solo despliegas código o configuración. Ejemplos: Azure App Service, AWS RDS, Google Cloud SQL. Reduce mantenimiento, aumenta dependencia.
- SaaS (Software as a Service): directamente consumes el software. Microsoft 365, Google Workspace, Salesforce, HubSpot. No gestionas nada por debajo.
- Cloud privado: infraestructura tipo nube en tu propio CPD o en uno dedicado. Tiene la elasticidad lógica del cloud público sin compartir hardware.
- Híbrido: combinas on-premise con uno o más proveedores cloud. Es lo que recomendamos en la mayoría de pymes industriales: lo crítico cerca de la planta, lo colaborativo y de respaldo en la nube.
Mezclar capas es habitual. Un cliente puede tener su ERP en IaaS, su correo en SaaS, su BI en PaaS y su servidor de archivos on-premise. No hay nada malo en ello si la arquitectura está pensada.
Lift-and-shift, replatform o refactor
Cuando migras una aplicación, hay tres caminos y rara vez se explican bien:
- Lift-and-shift (rehosting): coges la máquina virtual tal cual y la subes al cloud. Es rápido, pero te llevas todas las ineficiencias del original. Pagarás por recursos sobredimensionados que en local "no se notaban" porque ya estaban comprados.
- Replatform: haces ajustes mínimos para aprovechar servicios gestionados. Por ejemplo, sustituir tu SQL Server local por una base de datos gestionada (RDS, Azure SQL). Mantienes la lógica, ganas en operación, reduces parte del coste.
- Refactor: reescribes la aplicación para que sea cloud-native (contenedores, serverless, microservicios). Aporta el máximo aprovechamiento del cloud, pero el coste y el riesgo del proyecto se disparan. Solo tiene sentido si la aplicación va a vivir muchos años más y necesitas elasticidad real.
Para una pyme con un ERP estable, replatform suele ser el punto óptimo. Refactor completo casi nunca rentabiliza salvo que estés haciendo una transformación de producto.
Cuándo SÍ migrar al cloud
Hay escenarios donde la nube tiene un valor difícil de discutir:
- Cargas variables o estacionales. Si tu pico de Black Friday, campaña agraria o cierre fiscal multiplica por cinco la carga durante unas semanas, comprar hardware para ese pico es tirar dinero. La nube te permite escalar arriba y abajo y pagar por uso.
- Equipos remotos o multilocalización. Si tienes gente trabajando desde casa, oficinas en varias provincias o personal comercial en ruta, el SaaS resuelve el acceso sin VPN frágiles ni servidores expuestos.
- Recuperación ante desastres. Replicar tus datos críticos a otra región, con failover probado, es muchísimo más fácil y barato en cloud que montando un segundo CPD propio. Para muchas pymes, este es el caso más rentable de todos.
- Cumplimiento que requiere trazabilidad. Los hyperscalers traen registros, cifrado y certificaciones (ISO 27001, ENS, SOC 2) ya hechos. Si te las tienes que ver con auditorías serias, partir de un proveedor certificado te ahorra meses.
- Falta de equipo TI propio. Si no tienes a alguien que se ocupe del servidor a las dos de la madrugada cuando falla un disco, externalizar a SaaS o a un IaaS gestionado por un partner como nosotros tiene mucho sentido.
Cuándo NO migrar al cloud
Y los escenarios donde la cosa pinta peor:
- Servidor reciente amortizado y carga estable. Si compraste hardware hace dos años, lo tienes con garantía, la carga no crece y todo funciona, migrar ahora es destruir la inversión. Espera a la siguiente renovación de hardware (típicamente 5-7 años) y entonces decide.
- Latencia crítica en planta. Control de máquinas, MES, scada, visión artificial en línea de producción. La nube introduce decenas de milisegundos que pueden ser inaceptables. Aquí el patrón es edge en planta + cloud para reporting, no todo arriba.
- Datos con regulación estricta de localización. Hay sectores donde, por contrato o por normativa, los datos no pueden salir de territorio nacional o europeo. AWS, Azure y Google Cloud ofrecen regiones europeas, pero conviene mirar la letra pequeña sobre acceso desde EEUU bajo la CLOUD Act.
- Volúmenes grandes de datos con poca elasticidad. Si manejas terabytes que rara vez cambian de tamaño, almacenarlos en un NAS en local sale órdenes de magnitud más barato que en object storage cloud, especialmente si los lees con frecuencia (recuerda el egreso, ahora hablamos de eso).
- Aplicaciones legacy sin soporte. Mover una aplicación que solo funciona en Windows Server 2008 al cloud no resuelve el problema; lo encarece. Primero hay que decidir si esa aplicación tiene futuro o sustituirla.
Costes reales: la trampa del egreso y el "cuanto más uses, más pagas"
El error más común al calcular el coste de migrar es comparar el alquiler mensual de la VM cloud con la cuota de tu servidor físico amortizado. Faltan capítulos enteros:
- Tráfico de salida (egreso). Subir datos al cloud es gratis o casi. Sacarlos cuesta, según proveedor, entre unos pocos céntimos y varios céntimos por GB. Si haces backups o exportas datos al exterior con frecuencia, esta línea puede dispararse. Hetzner y OVH suelen ser claramente más baratos en egreso que los hyperscalers; tenlo en cuenta si tu carga genera mucho tráfico saliente.
- IOPS y almacenamiento de alto rendimiento. Los discos SSD rápidos en cloud se cobran por IOPS reservadas, no solo por GB. Una base de datos exigente puede salir el doble que su equivalente local.
- Snapshots, backups, logs y métricas. Servicios "auxiliares" que se contratan a la ligera y aparecen en factura cada mes.
- Coste humano de operar el cloud. Optimizar facturas, gestionar IAM, controlar costes y tener a alguien que entienda la consola del proveedor no es gratis. Según Gartner, hasta un 30% del gasto cloud se desperdicia por mal dimensionamiento; nuestra experiencia con clientes que llegan después de migrar solos lo confirma.
- Reservas y contratos a largo plazo. Comprar instancias reservadas a 1 o 3 años puede reducir el coste un 30-60%, pero te ata. Solo merece la pena cuando la carga es predecible.
- Coste de salida. Si dentro de cuatro años quieres cambiar de proveedor, sacar terabytes de datos y reescribir integraciones es un proyecto en sí mismo. Forrester y Gartner llevan años advirtiendo del vendor lock-in como uno de los riesgos principales de cloud. Es real.
Una regla práctica: si tu cálculo de migración no incluye egreso, backups, monitorización y horas de gestión, está mal hecho.
Proveedores comparados (sin fanboyismo)
Hablamos de los principales con los que solemos trabajar. No hay un "mejor" universal: hay encajes.
- AWS. El catálogo más amplio del mercado. Curva de aprendizaje empinada y facturación que sorprende si no la controlas. Idóneo para cargas grandes, equipos técnicos maduros o productos digitales.
- Microsoft Azure. Encaja muy bien si ya estás en el ecosistema Microsoft (Active Directory, 365, SQL Server, Dynamics). Integración nativa con identidad y licencias. Suele ser nuestra primera opción para pymes industriales con stack Windows.
- Google Cloud. Fuerte en datos, BigQuery, IA y Kubernetes. Catálogo más pequeño que AWS o Azure, pero competitivo en analítica.
- Hetzner. Proveedor europeo (Alemania, Finlandia). Precios muy agresivos, hardware potente, egreso generoso. Menos servicios gestionados, pero excelente para IaaS puro y servidores dedicados con buena relación calidad-precio.
- OVHcloud. Proveedor francés, datos en Europa, opción interesante para empresas con sensibilidad sobre soberanía del dato. Catálogo PaaS limitado frente a hyperscalers.
- On-premise propio. Sigue siendo válido. Servidor en tu CPD o en housing en un datacenter local. Coste predecible, control total, latencia mínima. A cambio: tú gestionas hardware, energía y disaster recovery.
Para pymes navarras, una combinación habitual y sensata es: Microsoft 365 para colaboración, ERP en servidor on-premise o cloud privado europeo, backups replicados a un segundo proveedor. Es híbrido, es soberano y es razonable en coste.
Hoja de ruta de migración por fases (3-12 meses)
Una migración seria no es un fin de semana largo. Así la planificamos nosotros:
- Mes 0-1: Auditoría e inventario. Aplicaciones, dependencias, volúmenes de datos, ventanas de mantenimiento, contratos vigentes, requisitos legales. Sin esto no se decide nada.
- Mes 1-2: Análisis coste-beneficio por carga. Cada aplicación se evalúa por separado. Algunas se migran, otras se quedan, otras se sustituyen por SaaS.
- Mes 2-3: Diseño de arquitectura objetivo y plan de salida. Sí, plan de salida desde el principio. Si en cinco años quieres cambiar, debe ser posible.
- Mes 3-5: Migración de cargas no críticas. Correo, colaboración, backups, entornos de pruebas. Aprendes con riesgo bajo.
- Mes 5-9: Migración de cargas medias. Servidores de archivos, aplicaciones internas, BI.
- Mes 9-12: Cargas críticas (ERP, producción). Solo cuando las anteriores estén estables. Con ventana, con plan de marcha atrás y con pruebas reales.
- Continuo: optimización. Revisión mensual de factura, FinOps, ajuste de tamaño de instancias.
En proyectos pequeños comprimimos esto a 3-4 meses. En migraciones de ERP o entornos industriales, hablamos de 9-12 sin forzar.
Riesgos comunes y cómo evitarlos
- Subestimar el egreso: pídele al proveedor un cálculo realista del tráfico de salida.
- Migrar sin medir antes: monitoriza una semana mínimo el rendimiento actual para tener línea base.
- Perder visibilidad de costes: activa alertas de presupuesto desde el día uno.
- Lock-in arquitectónico: usa servicios estándar (Postgres, Kubernetes, S3-compatible) cuando sea posible, evita servicios exclusivos del proveedor sin necesidad.
- Olvidar la formación: tu equipo necesita semanas para soltarse. Inclúyelo en el plan.
- No probar el disaster recovery: un backup que no se ha restaurado no es un backup.
Caso práctico: industrial con servidor físico de 5 años
Empresa industrial navarra, 60 empleados, ERP propio, servidor físico HPE comprado en 2021. Tres opciones sobre la mesa:
- Mantener on-premise (renovar hardware): requiere renovación de hardware con garantía y, además, energía, mantenimiento y licencias mensuales recurrentes. Coste mensual recurrente típico de un servidor on-premise: energía, soporte de hardware y licencias del SO. Latencia mínima a planta. Disaster recovery: pendiente de montar y supone un coste adicional si se quiere un segundo nodo en otra ubicación.
- Migrar todo a AWS (lift-and-shift): instancia equivalente, almacenamiento, backups y egreso facturados por uso. Ventaja: alta disponibilidad multi-AZ casi de serie y disaster recovery más sencillo. Inconvenientes: lock-in del proveedor, necesidad de FinOps para controlar la factura y latencia a planta peor que en local.
- Híbrido (lo que recomendaríamos): ERP en servidor renovado on-premise (latencia mínima y sin lock-in), Microsoft 365 para correo y colaboración, backups replicados a cloud europeo (Azure o un proveedor como Hetzner/OVH), servidor secundario en cloud apagado y listo para arrancar en caso de desastre. Equilibrio razonable entre latencia, disaster recovery real y dependencia del proveedor.
En el 80% de empresas con este perfil, la opción híbrida gana. No es la más glamurosa, pero es la que sale a cuenta.
Si tu ERP es Nieges, por ejemplo, lo desplegamos tanto on-premise como en cloud privado según convenga al cliente; no hay una única respuesta correcta.
Mini-FAQ
¿La nube es siempre más segura?
No. Es potencialmente más segura porque los proveedores invierten muchísimo en seguridad, pero la responsabilidad sigue siendo compartida. Una mala configuración de IAM en cloud expone más datos que un servidor on-premise mal mantenido.
¿Puedo volver atrás si me arrepiento?
Técnicamente sí, en la práctica es caro y lento. Diseña la arquitectura para minimizar la dependencia y planea la salida desde el principio.
¿Cuánto tarda una migración típica?
Entre 3 y 12 meses según complejidad. Desconfía de quien te prometa un cambio radical en semanas.
¿Necesito un equipo TI grande para gestionar cloud?
No necesariamente, pero sí necesitas a alguien que entienda lo que está pasando en la factura. Si no lo tienes en casa, externalízalo a un partner.
¿Es Hetzner u OVH una opción seria frente a AWS o Azure?
Para muchas cargas de pyme, sí. Tienen menos catálogo PaaS, pero mejor precio y datos en Europa. Conviene evaluarlos cuando el caso lo permita.
Artículos relacionados
¿Quieres una evaluación honesta de tu caso? Miramos tu inventario, costes y planes de crecimiento, y te decimos qué migrar, qué dejar en local y qué directamente sustituir. Contacta con nosotros: si no merece la pena migrar, te lo diremos.