Mundo Logística
SGA en la nube: qué es y cuándo compensa frente a on-premise
Elegir un sistema de gestión de almacenes es, sobre todo, elegir dónde va a vivir. La decisión entre un SGA en la nube (también llamado SaaS, software as a service) y un SGA on-premise (instalado en servidores propios) condiciona el coste inicial, el tiempo de puesta en marcha, quién mantiene el sistema funcionando y cuánto se puede adaptar a un proceso concreto. No es una pregunta técnica menor: marca el ritmo con el que un almacén puede crecer o cambiar de operativa en los próximos años.
Este artículo explica qué es un SGA en la nube, en qué se diferencia realmente del modelo on-premise más allá del tópico de «internet contra servidor propio», y qué criterios prácticos ayudan a decidir cuál compensa según el tamaño y la operativa del almacén.
Qué es un SGA en la nube
Un SGA (sistema de gestión de almacenes) en la nube es la misma herramienta que coordina ubicaciones, picking, inventario y expediciones, pero alojada en los servidores del proveedor y accesible por internet, normalmente mediante suscripción mensual o anual. La empresa no instala nada en su propio hardware: se conecta a través de un navegador o de una aplicación ligera, y el proveedor se encarga de mantener el servidor, aplicar actualizaciones y garantizar la disponibilidad.
El modelo on-premise, por contraste, instala el software en servidores propiedad de la empresa (físicos, en su centro de datos, o virtualizados en su propia infraestructura), y es el equipo de IT interno, o un proveedor contratado para ello, quien se encarga de mantenerlo, actualizarlo y protegerlo.
La diferencia no es solo «dónde está el servidor». Cambia también el modelo de coste (inversión inicial alta frente a cuota recurrente), quién asume el riesgo técnico del mantenimiento, y la velocidad con la que se puede escalar el sistema a más usuarios, más almacenes o más volumen.
Coste inicial y modelo de pago
El SGA on-premise exige una inversión inicial considerable: licencia del software, servidores propios o alquilados, y el trabajo de implantación técnica antes de que el sistema funcione. Ese desembolso se amortiza con los años, pero condiciona la tesorería del primer ejercicio.
El SGA en la nube reparte ese mismo coste en cuotas periódicas, normalmente por usuario, por almacén o por volumen de operaciones. La entrada es más barata y predecible, aunque a largo plazo, en operaciones muy estables y de gran volumen, el coste acumulado de las cuotas puede llegar a superar lo que habría costado la inversión inicial on-premise. Es un cálculo que conviene hacer a cinco años vista, no solo mirando el primer año.
Tiempo de implantación
Un SGA en la nube puede ahorrar el tiempo de montar servidores: el proveedor ya tiene la infraestructura lista, y el trabajo se centra en la configuración (ubicaciones, flujos, integraciones) y la formación del equipo. Aun así, el plazo real depende sobre todo del alcance. Una operación con procesos estándar y pocas integraciones puede estar en marcha en unas semanas; cuando hay que integrar el SGA con un ERP, un TMS y otros sistemas, es razonable contar con varios meses, y en proyectos con integraciones B2B complejas, entre tres y seis meses o más. Un SGA on-premise añade a ese mismo trabajo la instalación y puesta a punto de los servidores, lo que alarga el proyecto, a veces varios meses, especialmente si hace falta adquirir hardware nuevo.
Para un almacén que necesita empezar a operar pronto (una apertura, una temporada alta que se acerca, un cambio de operador logístico con fecha fija), el ahorro de la infraestructura propia puede pesar más que el coste a largo plazo, siempre que el plazo se haya acordado con el proveedor para el alcance concreto y no solo para una instalación básica.
Mantenimiento y actualizaciones
En la nube, el proveedor aplica las actualizaciones de forma continua y sin que el cliente tenga que planificar una parada del sistema para instalarlas. Es una ventaja real para almacenes sin equipo técnico propio dedicado a IT.
On-premise, cada actualización es un proyecto: hay que planificarla, probarla en un entorno de pruebas si existe, y ejecutarla en una ventana de mantenimiento que normalmente implica parar el sistema. A cambio, la empresa decide cuándo actualizar y puede posponer una versión si no le conviene en ese momento, algo que en la nube no siempre es negociable: el proveedor marca su propio calendario de versiones.
Personalización y control
Aquí el on-premise suele tener ventaja. Al controlar el servidor y, en muchos casos, el código, es más sencillo adaptar el sistema a un proceso muy específico del almacén: una regla de picking poco habitual, una integración con maquinaria antigua, un flujo de devoluciones particular del sector.
Los SGA en la nube son configurables (parámetros, reglas, integraciones vía API), pero rara vez permiten modificar el núcleo del software. Para operaciones con procesos muy estándar (que es la mayoría), esa limitación no llega a notarse. Para operaciones con procesos muy particulares, construidos durante años y difíciles de cambiar, puede ser un obstáculo real.
Seguridad y ubicación de los datos
Un proveedor de SGA en la nube serio invierte en seguridad (cifrado, copias de seguridad, redundancia) a una escala que una empresa mediana rara vez puede igualar por su cuenta. A cambio, los datos de la operación (stock, pedidos, en ocasiones datos de clientes) viven en servidores de un tercero, lo que exige revisar dónde están alojados físicamente esos datos y bajo qué normativa de protección de datos operan, especialmente si el proveedor no es europeo.
Conviene tener claro un matiz: pasar a la nube no traslada toda la seguridad al proveedor. Según el modelo de responsabilidad compartida que describe Microsoft, en cualquier tipo de despliegue en la nube el cliente sigue siendo responsable de sus datos, de la gestión de cuentas y usuarios y del control de acceso; el proveedor asume la infraestructura subyacente. En un SGA, eso significa preguntar cómo se gestionan los roles y permisos del personal del almacén, si hay doble factor de autenticación, qué registros de auditoría quedan y cómo se separan los datos de unos clientes de otros.
On-premise, la empresa mantiene el control físico y total sobre dónde viven sus datos, pero también asume por completo la responsabilidad de protegerlos: un servidor propio mal gestionado es, en la práctica, menos seguro que la infraestructura de un proveedor cloud especializado.
Integraciones con otros sistemas
Ningún SGA funciona aislado. Se conecta, casi siempre, con un ERP para sincronizar stock y facturación, con un TMS para coordinar el transporte de salida, y en operaciones de e-commerce, con la plataforma de venta online para actualizar disponibilidad en tiempo real.
Los SGA en la nube suelen resolver estas conexiones mediante API abiertas y conectores ya construidos para los ERP y plataformas de venta más habituales del mercado, lo que acelera la puesta en marcha de cada integración. Los SGA on-premise también pueden integrarse igual de bien, pero cada conexión suele requerir más desarrollo a medida, sobre todo si el sistema con el que hay que conectar es antiguo o propio de la empresa. No es una diferencia de si se puede integrar, sino de cuánto trabajo de desarrollo hace falta para lograrlo.
Vale la pena preguntar al proveedor, antes de firmar, con qué sistemas ya tiene experiencia de integración real y cuáles habría que construir desde cero: la respuesta cambia bastante el plazo real de implantación frente al plazo que aparece en la propuesta comercial.
Errores habituales al elegir el modelo de despliegue
Un error frecuente es decidir por el coste del primer año sin proyectar el gasto a cinco años vista, lo que lleva a subestimar el coste acumulado de las cuotas de un SGA en la nube en una operación grande y estable, o a sobrestimar la inversión inicial on-premise sin contar con que se amortiza en ese mismo periodo.
Otro es asumir que «en la nube» significa automáticamente «más rápido de implantar» sin comprobarlo con el proveedor concreto: la configuración de ubicaciones, reglas de picking e integraciones lleva su tiempo en cualquier modelo, y un proyecto cloud con muchas integraciones puede acercarse en plazo a uno on-premise.
Un tercero es no preguntar, antes de firmar, qué pasa con los datos si la empresa decide cambiar de proveedor más adelante: en qué formato se pueden exportar, en cuánto tiempo, y si el contrato retiene los datos como forma de presión para renovar. Es una cláusula que conviene revisar en cualquier contrato de software como servicio, no solo en un SGA.
Cuándo compensa el SGA en la nube
La nube suele ser la opción más razonable cuando el almacén tiene procesos relativamente estándar de picking, ubicación y expedición; cuando no hay un equipo de IT interno dedicado a mantener servidores; cuando la operación puede crecer o reducirse de forma no lineal (picos de temporada, apertura de nuevos almacenes) y conviene poder escalar el sistema sin comprar hardware nuevo cada vez; o cuando el proyecto tiene prisa y no hay margen para un plazo de implantación largo.
También compensa cuando la empresa gestiona varios almacenes o centros y necesita que todos vean el mismo sistema en tiempo real sin depender de una infraestructura central propia que conecte cada sede.
Cuándo sigue teniendo sentido el on-premise
El on-premise sigue siendo la opción correcta en operaciones de gran volumen y muy estables en el tiempo, donde el coste de las cuotas recurrentes de la nube acabaría superando la inversión inicial a medio plazo; en almacenes con procesos muy particulares que necesitan modificar el software en profundidad; en sectores con requisitos estrictos de dónde deben residir los datos por normativa propia; o en empresas que ya cuentan con un equipo de IT consolidado y prefieren mantener el control técnico completo del sistema.
Cómo decidir en la práctica
Más que elegir una etiqueta («nube» o «on-premise»), conviene responder a tres preguntas concretas sobre la operación real: cuánto va a variar el volumen de trabajo en los próximos tres años, si existe capacidad interna para mantener un servidor propio con garantías, y cuánto se aparta el proceso de picking y gestión de stock del estándar del sector. Cuanto más variable el volumen, más ligera la estructura de IT interna, y más estándar el proceso, más clara la balanza hacia la nube. Cuanto más estable el volumen, más consolidado el equipo técnico propio, y más particular el proceso, más sentido tiene seguir, o pasar, a on-premise.
Un software logístico bien elegido no es el que tiene más funciones, sino el que encaja con cómo funciona realmente el almacén hoy y cómo previsiblemente va a funcionar dentro de tres años. El modelo de despliegue, nube u on-premise, es una de las decisiones que más condiciona esa segunda parte, y es también una de las que más pesan al elegir un SGA/WMS concreto para el almacén.
Continuidad del almacén si falla la conexión o el sistema
Un SGA puede convertirse en un sistema crítico para la operación diaria: si no está disponible, la recepción, el picking, el packing o la expedición se pueden frenar en minutos. Conviene hacerse esta pregunta antes de firmar, no después del primer corte de servicio: qué ocurre exactamente si cae la conexión a internet del almacén, si existe algún procedimiento manual de contingencia para seguir despachando pedidos mientras se recupera el sistema, y qué dependencias locales (lectores, impresoras de etiquetas, radiofrecuencia, maquinaria automatizada) quedan sin sistema central durante ese tiempo.
En un SGA en la nube, esa pregunta se traduce en pedir al proveedor qué compromiso de servicio ofrece por contrato (el SLA), qué cubre exactamente y qué excluye (mantenimientos programados, fallos de la red del propio almacén, causas de fuerza mayor), y qué compensación prevé si no lo cumple, que suele ser un crédito de servicio y no la reparación del perjuicio operativo. Un SLA no garantiza que no haya caídas: fija un objetivo y sus consecuencias. Conviene pedir además dos cifras que a menudo se confunden: el tiempo máximo en el que se compromete a restablecer el servicio (RTO) y la cantidad máxima de datos recientes que podrían perderse (RPO), y preguntar cómo se prueba esa recuperación, no solo cómo se anuncia. En on-premise, la pregunta es la misma pero mirando hacia dentro: quién responde si el servidor propio falla fuera de horario, cómo se protegen las copias de seguridad y con qué frecuencia se verifica que realmente se pueden restaurar. Ninguno de los dos modelos elimina el riesgo de una caída por sí solo; lo que cambia es quién tiene que resolverla y con qué margen de tiempo.
Qué pasa con tus datos si cambias de proveedor
Un SGA acumula, con los meses, los datos esenciales de la operación: ubicaciones, históricos de movimientos, maestros de artículos y clientes, reglas de picking configuradas. Antes de firmar, conviene saber en qué formato se pueden exportar esos datos, si la exportación incluye el histórico completo o solo una foto del momento, y cómo se extraen las configuraciones y reglas de negocio que se hayan construido dentro del sistema, no solo los datos en bruto. Conviene distinguir entre exportar y migrar: exportar significa obtener los datos en un formato utilizable, y migrar significa que otro sistema los pueda cargar y funcionar igual. Los datos maestros y los históricos suelen poder exportarse; las reglas de picking, las estrategias de ubicación o las integraciones configuradas dentro del sistema muchas veces habrá que reconstruirlas en el nuevo, porque no existe un formato común que las traslade.
También conviene preguntar durante cuánto tiempo quedan disponibles los datos después de terminar el contrato, qué asistencia presta el proveedor durante ese proceso de salida, y si existe algún coste asociado a la extracción, aparte de la cuota habitual. En la Unión Europea, el Reglamento de Datos (Reglamento (UE) 2023/2854) regula el cambio de proveedor de servicios de tratamiento de datos en la nube, un concepto que en principio alcanza también al software como servicio. Desde el 12 de enero de 2027, el artículo 29.1 prohíbe los costes por cambio impuestos por el proveedor. Durante el periodo transitorio, los costes reducidos no pueden superar los costes directamente relacionados con el cambio. Esto no significa que toda migración sea gratuita: el artículo 31 establece excepciones para servicios desarrollados a medida y pruebas temporales. Aun así, no conviene darlo por resuelto: las penalizaciones por terminación anticipada de un contrato de plazo fijo o los servicios de apoyo adicionales pueden seguir existiendo si se pactaron, y el contrato debe respetar la normativa, de modo que se recomienda revisarlo con asesoramiento jurídico. Por último, merece la pena aclarar cómo y cuándo se eliminan las copias que el proveedor conserva una vez cerrado el contrato. Ninguna de estas preguntas afecta al día a día mientras todo funciona bien, pero sin respuesta clara, cambiar de proveedor más adelante puede acabar costando mucho más tiempo y dinero del que parecía al firmar.
Preguntas frecuentes
¿Un SGA en la nube es menos seguro que uno on-premise?
No necesariamente. Un proveedor cloud especializado suele invertir en seguridad a un nivel que una empresa mediana difícilmente puede igualar por su cuenta. La diferencia real está en dónde residen los datos y bajo qué normativa, no en que la nube sea intrínsecamente menos segura.
¿Se puede migrar de on-premise a la nube más adelante?
Sí, es una migración habitual en el sector, aunque exige planificación: exportar e integrar los datos históricos, revisar las integraciones existentes con otros sistemas (TMS, ERP) y formar de nuevo al equipo en la nueva interfaz.
¿El SGA en la nube funciona sin conexión a internet?
No se puede dar por hecho. Un SGA en la nube necesita conexión para operar con normalidad, y un funcionamiento sin conexión solo existe si el proveedor lo ofrece y lo documenta. En un almacén con varios operarios trabajando a la vez sobre las mismas ubicaciones y el mismo stock, además, seguir operando sin conexión es difícil de sostener, porque cada puesto trabajaría con datos que dejan de estar sincronizados. Lo prudente es pedir al proveedor qué funciones concretas siguen disponibles sin conexión, durante cuánto tiempo y cómo se concilian los datos al volver, y pedir una prueba o una demostración documentada, no una afirmación comercial. Más arriba, en la sección sobre continuidad, se explican las preguntas que conviene hacer al proveedor.
¿Cuánto cuesta un SGA en la nube frente a uno on-premise?
No hay una cifra única válida para todos los casos: depende del número de usuarios, del volumen de operaciones y del proveedor. Lo que sí es comparable es el patrón: la nube reparte el coste en cuotas periódicas desde el primer mes, mientras que on-premise concentra una inversión mayor al principio que se amortiza con los años. La decisión correcta depende de a cuántos años vista se mire el cálculo.