Business Central SaaS vs On-Premise: decide con costes, riesgos y futuro sobre la mesa
Compara infraestructura, seguridad, actualizaciones, personalizaciones, integración, Copilot e IA antes de comprometer los próximos años de tu ERP.
La diferencia no consiste únicamente en alojar Business Central en Microsoft Cloud o dentro de la infraestructura de la empresa. Cambian las responsabilidades, el coste total, la forma de actualizar, la capacidad para integrar el ecosistema Microsoft y el acceso a innovación. La decisión correcta debe responder al negocio, no a una preferencia técnica heredada.
SaaS debe ser la opción de partida para la mayoría. On-premise necesita una justificación empresarial concreta.
Business Central online suele tener más sentido cuando la organización quiere reducir infraestructura propia, mantener la plataforma actualizada, operar desde diferentes ubicaciones y conectar el ERP con Microsoft 365, Power Platform, Power BI, Copilot y los servicios cloud de Microsoft.
Business Central on-premise puede seguir siendo razonable cuando existen restricciones regulatorias documentadas, conectividad insuficiente, dependencia crítica de sistemas locales, requisitos específicos de control o una transición técnica que todavía no puede completarse.
Lo que no resulta defendible es mantener on-premise por inercia, por una percepción genérica de seguridad o porque nadie ha calculado el coste acumulado. Tampoco conviene elegir SaaS por moda sin revisar integraciones, personalizaciones, operación local y capacidad de cambio.
La prioridad es reducir carga tecnológica, actualizar de forma continua, escalar sin renovar servidores y construir una arquitectura conectada con automatización, datos e inteligencia artificial.
Existe una condición operativa, regulatoria o técnica demostrable que compensa asumir infraestructura, seguridad, copias, disponibilidad, actualizaciones y capacidad especializada.
Elegir SaaS porque “todo debe ir a la nube” o mantener on-premise porque “queremos tener el servidor”. Ninguna de esas frases sustituye un análisis serio.
Ocho decisiones que debes resolver
El producto comparte funcionalidad. El modelo de operación cambia la economía y el futuro del ERP.
La tabla resume las diferencias principales. No sustituye el diagnóstico, pero ayuda a detectar qué temas merecen una revisión detallada antes de decidir.
| Criterio | Business Central SaaS | Business Central On-Premise | Impacto |
|---|---|---|---|
| Infraestructura | Microsoft opera la infraestructura subyacente del servicio. | La empresa o su proveedor opera servidores, base de datos y componentes asociados. | SaaS reduce carga técnica. On-premise amplía el perímetro bajo responsabilidad del cliente. |
| Actualizaciones | El servicio se mantiene actualizado mediante ciclos gestionados y ventanas programables. | El cliente planifica, instala, prueba y mantiene la versión dentro de la política de soporte. | Aplazar versiones puede convertir el siguiente salto en un proyecto complejo. |
| Coste | Suscripción que incorpora la plataforma cloud principal. | Licencias, infraestructura, SQL, almacenamiento, copias, monitorización, soporte y renovaciones. | Comparar solo el precio por usuario produce una visión incompleta. |
| Continuidad | El servicio incluye capacidades administradas de redundancia, copia y recuperación. | La arquitectura de continuidad debe diseñarse, operarse, financiarse y probarse. | Una copia disponible no equivale a un plan de recuperación probado. |
| Copilot y agentes | Las capacidades nativas de Copilot se ofrecen en Business Central online. | Puede conectarse IA externa mediante una arquitectura específica, pero no ofrece la misma experiencia nativa. | La estrategia de IA ya influye en el modelo de despliegue. |
| Ecosistema Microsoft | Integración directa con Microsoft 365, Power Platform, Power BI, Dataverse y servicios cloud. | La integración es posible, pero puede necesitar más componentes y mantenimiento. | Un ERP aislado reduce el retorno del ecosistema Microsoft. |
| Personalización | Modelo basado en extensiones y aplicaciones preparadas para actualizarse. | Mayor control del entorno, con riesgo de conservar código heredado difícil de evolucionar. | Más libertad técnica no garantiza menor coste ni mejor arquitectura. |
| Escalabilidad | La plataforma absorbe buena parte de la gestión de capacidad. | El crecimiento puede requerir ampliar o rediseñar infraestructura y operación. | Deben valorarse usuarios, sociedades, datos, integraciones y volumen transaccional. |
Síntesis: SaaS transfiere una parte relevante de la operación tecnológica a Microsoft. On-premise conserva más control sobre la plataforma, pero mantiene dentro de la organización más costes, decisiones y riesgos.
La diferencia crítica es quién debe conseguir que todo siga funcionando
En SaaS, Microsoft opera la infraestructura del servicio y mantiene la plataforma. La empresa continúa siendo responsable de sus usuarios, identidades, permisos, datos, configuración, extensiones, integraciones, adopción y gobierno.
En on-premise, a esas responsabilidades se añaden servidores, sistemas operativos, base de datos, almacenamiento, certificados, copias, monitorización, disponibilidad, recuperación, parches, capacidad y actualización de componentes.
Externalizar estas tareas no las elimina. Las convierte en contratos, niveles de servicio, dependencias y costes. Por eso la pregunta no es cuánto control quiere la empresa, sino qué control necesita y si tiene capacidad real para ejercerlo.
Datos, usuarios, roles, segregación de funciones, procesos, extensiones, integraciones, formación, soporte funcional y decisiones sobre la evolución.
Infraestructura principal, despliegue de plataforma, disponibilidad del servicio, mantenimiento estándar y evolución continua.
Plataforma, base de datos, capacidad, seguridad, copias, recuperación, parches, instalación de versiones y soporte técnico.
La prueba del control real
Si el entorno deja de estar disponible, ¿quién recupera el servicio, con qué copia, en cuánto tiempo, con qué pérdida máxima de datos y cuándo se probó el procedimiento por última vez? Si la respuesta no es concreta, la sensación de control on-premise puede ser más teórica que operativa.
La licencia es visible. El coste de sostener la decisión se reparte por toda la organización.
Comparar modelos únicamente por el precio de licencia lleva a una conclusión pobre. El análisis debe cubrir tres o cinco años e incluir proyecto, operación, infraestructura, seguridad, actualización, soporte, dedicación interna, riesgo y coste de oportunidad.
En SaaS, la suscripción concentra una parte importante del coste de plataforma. Siguen existiendo implantación, soporte, evolución, extensiones, datos e integraciones, pero disminuye el peso de operar infraestructura y ejecutar grandes saltos técnicos.
En on-premise, parte del gasto queda disperso entre IT, contratos, servidores, SQL, almacenamiento, copias, monitorización, renovaciones, horas internas y proyectos puntuales. Esa dispersión puede hacer que parezca más barato de lo que realmente es.
Incluye licencias, infraestructura, soporte, contratos, renovaciones y proyectos, pero también el tiempo de IT, finanzas, operaciones y usuarios clave dedicado a mantener, probar y resolver.
Mide qué automatizaciones, integraciones, mejoras de reporting o proyectos de IA se aplazan y qué impacto tendría una caída, una recuperación incompleta o una versión obsoleta.
On-premise no es automáticamente más seguro. SaaS tampoco elimina la responsabilidad.
La seguridad depende de identidad, permisos, configuración, dispositivos, datos, extensiones, integraciones, monitorización, procedimientos y capacidad de respuesta. La ubicación de la infraestructura es una parte del diseño, no una garantía.
Plataforma administrada y continuidad integrada
El servicio incorpora capacidades administradas de disponibilidad, redundancia, copia y recuperación. Microsoft mantiene la plataforma y sus componentes dentro de un modelo de servicio continuo.
Esto reduce la dependencia de un servidor concreto, una copia manual o un procedimiento de recuperación que nunca se ha ensayado.
Identidades, permisos, datos y uso de la plataforma
La empresa debe gobernar usuarios, roles, segregación, dispositivos, extensiones, integraciones, datos, formación y procedimientos.
Una cuenta con permisos excesivos, una integración insegura o un proceso mal diseñado siguen siendo riesgos aunque el ERP esté en SaaS.
Protección de sistemas, base de datos, comunicaciones, copias, redundancia y recuperación
Además de gobernar el ERP, el cliente debe mantener actualizados y protegidos sus componentes, monitorizar su estado y comprobar que el plan de continuidad funciona. El riesgo no está solo en diseñarlo mal, sino en dejar de revisarlo mientras crecen los datos, las integraciones y las amenazas.
SaaS convierte la actualización en una disciplina continua. On-premise permite aplazarla, y ahí empieza la deuda.
Business Central online tiene dos grandes ciclos de actualización al año, con versiones principales en abril y octubre, además de actualizaciones menores. Los administradores pueden gestionar ventanas y fechas, recibir notificaciones y utilizar entornos de prueba para preparar el cambio.
Este modelo obliga a mantener extensiones, integraciones y procesos compatibles. Puede parecer exigente, pero evita acumular cinco años de retraso hasta convertir la siguiente actualización en un proyecto de alto riesgo.
En on-premise, la empresa controla el calendario. Esa flexibilidad puede ser útil para operaciones críticas, pero se vuelve peligrosa cuando aplazar la actualización deja de ser una excepción y se transforma en la forma habitual de operar.
La actualización forma parte del servicio. La responsabilidad se concentra en probar procesos, validar extensiones, revisar integraciones y preparar usuarios.
El cliente controla la instalación, pero debe mantenerse dentro de las políticas de soporte y asumir preparación técnica, despliegue y resolución de incompatibilidades.
Actualizar con frecuencia exige disciplina. No actualizar exige asumir que el coste, el riesgo y la dependencia técnica se acumularán para más adelante.
La inteligencia artificial ya forma parte de la decisión SaaS vs On-Premise
Microsoft ofrece las capacidades nativas de Copilot en Business Central online. La evolución del producto incorpora asistencia generativa y agentes orientados a procesos empresariales, como ventas y cuentas a pagar.
Una empresa con Business Central on-premise puede conectar servicios de IA, Azure o Copilot Studio mediante una arquitectura propia. Sin embargo, eso exige resolver seguridad, contexto, integración, permisos, mantenimiento y capacidad de actuación sobre los datos.
Si la organización quiere que el ERP sea la base para automatización inteligente, consultas en lenguaje natural, agentes o decisiones con contexto, mantener on-premise debe justificarse también frente al coste de oportunidad de acceder más tarde a estas capacidades.
La nube no impide adaptar Business Central. Obliga a separar diferenciación real de deuda técnica.
Uno de los argumentos más utilizados para conservar on-premise es la personalización. Antes de aceptarlo, conviene clasificar qué desarrollos generan valor, cuáles compensaban limitaciones antiguas y cuáles se mantienen porque nadie quiere asumir la decisión de retirarlos.
Diferenciación real
Procesos, cálculos, controles o integraciones que aportan una ventaja empresarial concreta y no pueden resolverse correctamente con estándar, configuración o aplicaciones disponibles.
Herencia funcional
Desarrollos creados por limitaciones antiguas de NAV o Business Central, procesos que ya han cambiado e informes que hoy podrían resolverse mediante capacidades estándar o analítica moderna.
Deuda técnica que condiciona cada actualización
Código difícil de mantener, modificaciones directas, dependencias de versiones antiguas, integraciones sin documentación y conocimiento concentrado en personas o proveedores concretos. Conservarlo puede parecer prudente, pero suele elevar el coste de cada cambio.
Cómo se personaliza en SaaS
La adaptación se plantea mediante configuración, extensiones, aplicaciones e integraciones capaces de convivir con actualizaciones. Esto exige más gobierno, pero reduce el riesgo de modificar el núcleo hasta hacerlo imposible de evolucionar.
También obliga a evaluar primero la funcionalidad estándar, el ecosistema de aplicaciones y Power Platform antes de construir un desarrollo desde cero.
Qué aporta el control on-premise
La organización puede conservar componentes, integraciones o desarrollos locales que todavía sean críticos. Esa flexibilidad puede ser necesaria, pero también facilita posponer su transformación.
Antes de usar la personalización como argumento, conviene inventariar qué aporta valor, qué puede convertirse en extensión y qué debería desaparecer.
No elijas el modelo que conserva mejor el pasado. Elige el que soporta mejor el negocio que quieres construir.
Si la organización prepara crecimiento, nuevas sociedades, automatización, analítica avanzada, trabajo distribuido o una estrategia de IA, la decisión debe evaluarse contra ese horizonte. Mantener una arquitectura durante un periodo transitorio puede ser razonable. Convertirla en la estrategia de los próximos cinco años exige argumentos más sólidos.
Cuándo encaja mejor cada modelo
No existe una respuesta universal. Sí existen patrones que permiten identificar cuándo una alternativa parte con ventaja y qué condiciones deben verificarse.
Empresa mediana que quiere modernizar NAV
Utiliza una versión antigua, mantiene personalizaciones controlables, depende de Excel para reporting y quiere integrar Microsoft 365, Power BI y automatización.
Decisión probable: Business Central online permite modernizar el ERP y reducir infraestructura. El proyecto debe revisar desarrollos y datos para evitar reproducir el NAV anterior.
Grupo con varias sedes o crecimiento previsto
Necesita acceso seguro desde distintas ubicaciones, incorporar usuarios y sociedades y conectar aplicaciones cloud sin ampliar continuamente la infraestructura.
Decisión probable: SaaS simplifica despliegue, capacidad y acceso, siempre que la arquitectura de identidades, datos e integraciones esté gobernada.
Industria con sistemas locales críticos
Dispone de MES, básculas, maquinaria, almacenes automáticos o integraciones que requieren baja latencia y continuidad local.
Decisión probable: no debe asumirse que on-premise es obligatorio. Puede diseñarse una arquitectura híbrida, pero hay que validar conectividad, latencia y operación ante una caída.
Restricción regulatoria o soberanía específica
La organización dispone de una exigencia formal sobre ubicación, aislamiento u operación que no puede satisfacerse mediante el servicio online disponible.
Decisión probable: on-premise puede ser correcto, pero debe cuantificarse su coste y revisarse periódicamente si la restricción sigue vigente.
Entorno muy personalizado y sin documentación
El ERP contiene código heredado, integraciones poco conocidas, informes críticos y procesos que dependen de pocas personas.
Decisión probable: ni migrar deprisa ni quedarse quieto. Primero se necesita una auditoría funcional y técnica que separe valor, deuda y riesgo.
Hoja de ruta de automatización e IA
La empresa quiere conectar el ERP con Power Platform, Power BI, Copilot, agentes, Azure y procesos digitales alrededor de finanzas y operaciones.
Decisión probable: Business Central online ofrece una base más directa, siempre que dato, permisos e integraciones estén gobernados.
Cómo pasar de Business Central on-premise a SaaS sin trasladar toda la deuda
Migrar a Business Central online no debería consistir en mover una base de datos y conservar cada decisión histórica. El proyecto debe determinar qué datos, desarrollos, integraciones y procesos merecen llegar al nuevo entorno.
Microsoft proporciona herramientas de migración desde versiones admitidas de Business Central on-premise. La viabilidad técnica no sustituye el análisis funcional: una migración puede completarse correctamente y seguir reproduciendo procesos lentos, datos inconsistentes y personalizaciones sin valor.
Las versiones antiguas de NAV pueden requerir pasos intermedios y conversión de personalizaciones antes de llegar a un escenario compatible con la migración cloud. La ruta debe validarse con la versión real y no con supuestos.
La migración debe reducir dependencia y preparar el ERP para evolucionar, no limitarse a cambiar la ubicación del mismo problema.
Diagnóstico del entorno
Identificar versión, infraestructura, base de datos, usuarios, sociedades, personalizaciones, aplicaciones, integraciones, informes y procesos críticos.
Clasificación de personalizaciones
Separar diferenciación real, configuración, funcionalidad estándar, aplicaciones existentes, desarrollos convertibles y deuda que debe retirarse.
Decisión sobre los datos
Definir qué maestros, saldos, movimientos e históricos se trasladan, qué se archiva y qué debe limpiarse antes de entrar en el nuevo entorno.
Arquitectura objetivo
Diseñar identidades, entornos, integraciones, extensiones, seguridad, reporting, Power Platform y responsabilidades de operación.
Pruebas con procesos reales
Validar cierres, compras, ventas, almacén, fabricación, proyectos, tesorería, integraciones, informes y excepciones, no solo pantallas aisladas.
Transición y evolución
Preparar formación, soporte al arranque, contingencia y una hoja de ruta posterior para automatización, analítica, Copilot y agentes.
Preguntas que deben responderse antes de elegir
Una decisión sólida debe poder explicarse en términos de coste, riesgo, operación, crecimiento y capacidad de evolución.
¿Qué versión utilizamos, qué infraestructura la soporta y qué componentes están cerca de quedar obsoletos?
¿Conocemos el coste a tres y cinco años o solo estamos comparando licencias y un presupuesto inicial?
¿Qué nivel de servicio necesita el negocio y cómo se recuperaría el ERP ante una caída grave?
¿Qué desarrollos generan valor real y cuáles solo compensan decisiones o limitaciones del pasado?
¿Qué sistemas dependen del ERP, cómo se conectan y qué impacto tendría cambiar el modelo?
¿Existe una restricción formal que impida SaaS o estamos trabajando con supuestos no verificados?
¿Quién conoce infraestructura, código e integraciones, y qué ocurriría si ese conocimiento desaparece?
¿Qué papel tendrán Power Platform, Power BI, Copilot, agentes y Azure durante los próximos años?
La decisión no termina al elegir SaaS u on-premise
Ayesa analiza el modelo de despliegue dentro de una estrategia más amplia: procesos, datos, seguridad, integraciones, coste, adopción, automatización y evolución hacia inteligencia artificial.
El objetivo no es forzar una migración cloud. Es determinar qué arquitectura reduce riesgo, mejora la operación y permite evolucionar sin pagar cada cambio como un nuevo proyecto de rescate.
Versión, infraestructura, datos, desarrollos, integraciones, soporte y riesgos actuales.
TCO, inversión de migración, costes recurrentes, esfuerzo interno y coste de oportunidad.
Business Central, Microsoft 365, Power Platform, Power BI, Azure, Copilot y soluciones sectoriales.
Fases, prioridades, migración, pruebas, adopción, soporte y evolución posterior.
Sigue construyendo la decisión
El despliegue debe conectarse con el coste, la modernización del ERP, las integraciones y la estrategia de automatización e inteligencia artificial.
Dynamics 365 Business Central
Capacidades, implantación, migración, comparativas, integraciones y evolución del ERP Microsoft.
Cuánto cuesta Business Central
Licencias, implantación, migración, integraciones, soporte y escenarios reales de presupuesto.
Modernización ERP Microsoft
Qué conservar, qué rediseñar y cómo conectar ERP, datos, automatización, seguridad e IA.
Power Platform conectada al ERP
Aplicaciones, flujos, datos y procesos alrededor del ERP sin convertirlo en un bloque monolítico.
Integraciones Business Central
Cómo conectar ERP, CRM, Microsoft 365, Power Platform, aplicaciones sectoriales y sistemas externos.
Comparativas ERP Microsoft
Guías para comparar Business Central, Dynamics 365 Finance y otras alternativas con criterio empresarial.
Dudas habituales sobre Business Central SaaS y On-Premise
¿Business Central SaaS y Business Central online son lo mismo?
Sí. Ambos términos se refieren al modelo cloud en el que Microsoft presta Business Central como servicio mediante suscripción y gestiona la infraestructura de la plataforma.
¿Business Central on-premise sigue teniendo soporte?
Microsoft mantiene versiones on-premise bajo sus políticas de ciclo de vida. El cliente debe conservar el software actualizado y cumplir las condiciones de mantenimiento y soporte aplicables a su versión.
¿SaaS es siempre más barato?
No en cualquier comparación puntual. Depende de usuarios, infraestructura, personalizaciones, integraciones y horizonte. SaaS suele reducir costes de plataforma y actualización, pero implantación y evolución siguen requiriendo inversión.
¿On-premise ofrece más control?
Ofrece más control sobre infraestructura, versiones e instalación. También añade responsabilidad sobre mantenimiento, disponibilidad, copias, seguridad, capacidad y recuperación.
¿Se puede personalizar Business Central SaaS?
Sí. Puede adaptarse mediante configuración, extensiones, aplicaciones e integraciones. La arquitectura debe estar preparada para convivir con actualizaciones continuas.
¿Qué ocurre con las personalizaciones antiguas?
Deben inventariarse y clasificarse. Algunas se convierten en extensiones, otras se sustituyen mediante estándar o aplicaciones y otras deberían retirarse para no trasladar deuda al nuevo entorno.
¿Las actualizaciones de Business Central online son obligatorias?
El servicio se mantiene actualizado dentro de los ciclos definidos por Microsoft. Los administradores pueden gestionar ventanas y probar previamente, pero no conservar una versión antigua de forma indefinida.
¿Copilot está disponible en Business Central on-premise?
Las capacidades nativas de Copilot son exclusivas de Business Central online. Un entorno local puede conectarse con soluciones externas de IA, pero necesita una arquitectura específica.
¿Puede una fábrica trabajar con Business Central SaaS?
Sí, pero debe revisarse la integración con maquinaria, MES, SGA, básculas y otros sistemas locales. En algunos casos será necesaria una arquitectura híbrida.
¿Se pueden migrar todos los datos históricos?
La posibilidad depende de la ruta y la estructura de datos. La conveniencia debe analizarse: no siempre aporta valor trasladar todos los históricos al ERP operativo.
¿Cuánto dura una migración a SaaS?
Depende de versión, sociedades, datos, personalizaciones, integraciones y alcance. Un diagnóstico distingue una migración relativamente directa de una reimplantación completa.
¿Cómo saber qué opción necesita mi empresa?
Hay que analizar versión, infraestructura, regulación, coste total, personalizaciones, integraciones, disponibilidad, crecimiento, capacidad interna y estrategia de automatización e IA.
Criterios contrastados con Microsoft Learn
La comparación se apoya en la documentación oficial sobre el servicio online, ciclos de actualización, soporte on-premise, diferencias funcionales, migración a la nube y disponibilidad de Copilot.
¿Mantener Business Central on-premise o pasar a SaaS?
Podemos revisar tu versión, infraestructura, personalizaciones, integraciones, costes, riesgos y hoja de ruta para determinar qué modelo tiene más sentido y qué supondría realizar el cambio.