Business Central SaaS vs On-Premise: decide con coste total, riesgo y futuro sobre la mesa
Infraestructura, seguridad, actualizaciones, personalizaciones, integración, continuidad, Copilot, agentes, TCO y capacidad de evolución: la decisión no va de “nube sí o no”, sino de qué modelo puedes gobernar mejor durante los próximos cinco años.
Business Central online y Business Central on-premises comparten una base funcional, pero no representan la misma forma de operar el ERP. En SaaS, Microsoft asume la infraestructura del servicio y la plataforma se mantiene dentro de un ciclo continuo de actualización. En on-premise, la empresa conserva más control técnico, pero también asume servidores, base de datos, seguridad, copias, recuperación, parches, versiones y parte de la complejidad futura. Elegir bien exige cuantificar responsabilidades, coste total, restricciones reales y oportunidad de evolución.
Para la mayoría de empresas nuevas o modernizaciones, SaaS debería ser la opción de partida. On-premise debe justificar su excepción.
Business Central online parte con ventaja cuando la organización quiere reducir carga de infraestructura, mantener el ERP actualizado, integrar Microsoft 365, Power Platform, Power BI y servicios cloud, acceder a Copilot y evitar grandes saltos de versión que se conviertan en proyectos cada pocos años.
On-premise puede seguir teniendo sentido cuando existe una restricción técnica, regulatoria u operativa demostrable: conectividad insuficiente, sistemas locales muy sensibles a latencia, exigencias específicas de aislamiento, dependencia de componentes no compatibles con online o un contexto de transición que todavía no puede resolverse.
Lo que no debería ser argumento suficiente es “queremos tener el servidor”, “la nube es menos segura” o “no queremos que Microsoft nos actualice”. Esas frases expresan preferencias, no una evaluación de riesgo.
La decisión correcta responde a otra pregunta: ¿qué modelo reduce mejor el coste total, la deuda técnica, la exposición operativa y la fricción para evolucionar durante los próximos años?
La funcionalidad puede parecer parecida. La economía operativa y la responsabilidad cambian mucho.
La tabla no sustituye un diagnóstico. Sirve para identificar qué temas deben cuantificarse antes de que la organización adopte una postura por preferencia técnica.
| Criterio | Business Central SaaS | Business Central On-Premise | Impacto de decisión |
|---|---|---|---|
| Infraestructura | Microsoft opera la infraestructura del servicio. | Cliente/proveedor opera servidores, SQL y plataforma. | SaaS reduce perímetro técnico propio. |
| Actualización | Ciclo continuo; 2 grandes releases/año y menores frecuentes. | Cliente controla cuándo instalar y debe mantenerse soportado. | Flexibilidad vs riesgo de acumular deuda. |
| Copilot | Capacidades nativas disponibles según región/función. | Copilot nativo de Business Central no disponible. | Impacta roadmap de IA. |
| Control técnico | Menor control sobre infraestructura base. | Mayor control de servidores, versiones y componentes. | Control útil solo si aporta valor y puede ejercerse. |
| Personalización | Extensiones/apps compatibles con actualizaciones. | Mayor libertad técnica, pero también más riesgo de dependencia. | Diferenciación vs deuda. |
| Continuidad | Responsabilidad del servicio compartida con Microsoft. | Cliente debe diseñar y operar backup, HA y DR. | Debe medirse RTO/RPO y pruebas reales. |
| Integración | APIs y ecosistema Microsoft cloud como patrón natural. | Puede integrar local/cloud, pero exige más diseño de infraestructura. | Importa especialmente con MES/SGA/EDI. |
| Coste total | Suscripción + proyecto + soporte + evolución. | Licencia/planes + infraestructura + SQL + backup + operación + upgrades + soporte. | Comparar a 3/5 años, no solo año 1. |
SaaS no elimina la responsabilidad del cliente. Elimina una parte de la plataforma que el cliente debe operar.
En Business Central online, Microsoft opera la infraestructura del servicio y mantiene la plataforma. La organización sigue siendo responsable de usuarios, permisos, configuración, datos, extensiones, integraciones, procesos, formación, adopción y gobierno. Un ERP SaaS mal gobernado puede seguir siendo inseguro, inconsistente o caro.
En on-premise, a esas responsabilidades se suman servidores, sistema operativo, SQL Server, certificados, capacidad, almacenamiento, copias, monitorización, redundancia, recuperación, parches y actualización de versiones. Externalizarlo a un tercero no hace desaparecer la responsabilidad: la convierte en contrato, SLA y dependencia.
On-premise puede parecer más barato porque parte del coste está repartido entre presupuestos que nadie suma.
SaaS concentra más coste en la suscripción y reduce el peso de operar infraestructura. On-premise reparte gasto entre servidores, SQL, almacenamiento, backup, seguridad, monitorización, renovación, horas internas, contratos y proyectos de actualización. Si cada partida pertenece a un centro de coste diferente, la comparación puede estar sesgada.
El TCO debe construirse para un horizonte de tres y cinco años e incluir también el coste de oportunidad: cuánto tarda la empresa en actualizar, qué innovaciones llegan tarde y cuánta capacidad IT queda ocupada manteniendo infraestructura en lugar de mejorar procesos.
Coste más visible y predecible
Suscripción, implantación, soporte, extensiones, apps, integraciones, formación, datos y evolución. Menor necesidad de presupuestar infraestructura propia del ERP.
Más costes dispersos
Infraestructura, SQL, almacenamiento, copias, monitorización, seguridad, personal técnico, upgrades, soporte, energía, renovación y continuidad.
| Partida 3–5 años | SaaS | On-Premise | Pregunta CFO/CIO |
|---|---|---|---|
| Plataforma | Incluida en servicio. | Infraestructura propia/hosting. | ¿Quién paga renovación? |
| Base de datos | Gestionada dentro del servicio. | SQL, licencias/capacidad y operación. | ¿Está realmente imputado? |
| Actualización | Continua; foco en compatibilidad funcional. | Proyecto técnico + funcional. | ¿Cuánto cuesta cada salto? |
| Continuidad | Servicio Microsoft + gobierno cliente. | Backup, DR, pruebas y operación. | ¿RTO/RPO probados? |
| Innovación | Acceso más directo a nuevas capacidades online. | Depende de versión e integración propia. | ¿Qué valor se retrasa? |
On-premise no es automáticamente más seguro. SaaS tampoco te libera de gobernar seguridad.
La seguridad de un ERP depende de identidad, permisos, segregación, extensiones, integraciones, dispositivos, datos, monitorización y procedimientos. La ubicación del servidor es solo una pieza. Un entorno local sin parches, MFA, segmentación o backup probado puede ofrecer menos seguridad real que un servicio cloud correctamente gobernado.
Business Central online se ejecuta como servicio cloud sobre Microsoft Azure y se apoya en prácticas y certificaciones de servicio de Microsoft. La organización sigue necesitando proteger usuarios, roles e integraciones. En on-premise, además, debe endurecer servidor, comunicaciones, base de datos, sistema operativo y acceso administrativo.
Identidad
MFA, mínimos privilegios, cuentas de administración y ciclo de altas/bajas.
Permisos
Roles, segregación, acceso por responsabilidad y revisión periódica.
Integraciones
OAuth, secretos/certificados, scopes, cuentas técnicas y trazabilidad de llamadas.
On-Premise
Hardening de servidores, SQL, red, certificados, parches, backup y recuperación.
SaaS
Gobierno de tenant, admins, roles, extensiones, apps, datos e integraciones.
Respuesta
No basta con prevenir: hay que saber detectar, contener, recuperar y aprender.
“Tenemos backup” no es un plan de continuidad.
Para evaluar on-premise con rigor hay que conocer RTO, RPO, redundancia, ubicación de copias, proceso de restauración, dependencias externas, credenciales de emergencia y frecuencia de pruebas. Una copia que nunca se ha restaurado no demuestra recuperación.
En SaaS, Microsoft asume continuidad de la infraestructura del servicio, pero la empresa sigue necesitando gobernar datos, identidades, integraciones y procedimientos internos. También debe entender qué ocurre con procesos externos cuando Business Central o una integración no están disponibles.
SaaS convierte actualizar en disciplina continua. On-premise permite aplazar, y ahí puede empezar la deuda.
Microsoft organiza Business Central online en dos grandes ciclos de actualización al año, con releases principales en abril y octubre, y actualizaciones menores durante el resto del año. Los administradores pueden gestionar ventanas de actualización y utilizar sandbox para validar extensiones y procesos.
Este ritmo exige mantener extensiones e integraciones compatibles. Eso es una obligación real, no una ventaja gratuita. Pero evita convertir una acumulación de años en una actualización extraordinaria con alto riesgo.
On-premise ofrece más control de calendario, pero Microsoft también exige mantenerse en versiones soportadas según su política de ciclo de vida. Posponer sistemáticamente actualizaciones no elimina el coste: lo concentra más adelante.
Actualización continua
La plataforma se mueve. Tu responsabilidad es mantener procesos, extensiones e integraciones preparadas y probar antes de cada cambio relevante.
Actualización controlada
La organización controla instalación, pero debe mantener soporte, preparar infraestructura, ejecutar upgrade y resolver incompatibilidades.
La IA ya forma parte de la decisión de despliegue: Copilot en Business Central es exclusivo del servicio online.
Microsoft confirma que las capacidades nativas de Copilot de Business Central están disponibles únicamente en Business Central online. La disponibilidad concreta de cada función depende de región, idioma y versión, pero el principio de despliegue es claro: on-premise no incorpora Copilot nativo.
Un entorno on-premise puede conectarse con Azure AI, Copilot Studio u otros servicios mediante una arquitectura específica. Eso no es equivalente a disponer de las capacidades nativas del producto: hay que resolver identidad, permisos, contexto, integración, seguridad, mantenimiento y trazabilidad de acciones.
Si la empresa quiere convertir ERP, Power Platform, Microsoft 365, datos y agentes en una hoja de ruta común, mantener on-premise debe justificarse también frente al coste de oportunidad de llegar más tarde a parte de esa innovación.
Copilot nativo
Business Central online es el modelo soportado por Microsoft para sus capacidades de Copilot.
Agentes
La evolución del producto online incorpora capacidades orientadas a automatizar tareas con contexto empresarial.
On-Premise + IA
Posible mediante servicios externos y arquitectura propia, con mayor responsabilidad de integración.
Permisos
La IA necesita los mismos principios de mínimo privilegio, identidad y trazabilidad que cualquier automatización crítica.
Datos
Un agente no arregla maestros pobres, procesos fuera del sistema ni definiciones ambiguas.
Roadmap
Evalúa no solo qué necesitas hoy, sino qué automatización quieres poder introducir mañana.
La nube no elimina la personalización. Obliga a distinguir diferenciación de deuda técnica.
Uno de los argumentos más frecuentes para mantener on-premise es que “tenemos demasiada personalización”. Esa afirmación debe convertirse en un inventario. Cada desarrollo debería clasificarse por uso, valor, dependencia, complejidad, datos y alternativa disponible.
Business Central moderno es extension-based y utiliza AL. La migración a online exige que la funcionalidad no estándar se transforme en apps o extensiones compatibles o se replantee. Esto puede aumentar esfuerzo inicial, pero también ofrece la oportunidad de eliminar modificaciones que solo sobrevivían por inercia.
SaaS no significa que todo deba estar en cloud. Significa que la integración necesita una arquitectura explícita.
Una fábrica puede mantener MES, básculas, etiquetado, maquinaria, SGA, sistemas de calidad o dispositivos locales y utilizar Business Central online como núcleo transaccional. La clave es diseñar conectividad, latencia, buffers, colas, reintentos y operación ante caída.
No debe asumirse que una dependencia local obliga a mantener todo el ERP on-premise. Tampoco debe asumirse que cualquier sistema local puede integrarse a SaaS sin analizar estabilidad de red, ventanas de operación y criticidad.
APIs
Patrón de integración mantenible para entidades y operaciones del ERP.
Middleware
Azure y servicios de integración pueden desacoplar sistemas y gestionar transformación, colas y observabilidad.
Power Platform
Automatización y aplicaciones periféricas alrededor del ERP con gobierno.
Edge/local
Procesos que necesitan seguir operando localmente ante pérdida temporal de conectividad.
Observabilidad
Detectar errores, latencia, duplicidad y mensajes pendientes antes de que afecten al negocio.
Ownership
Definir sistema maestro, responsabilidad y procedimiento cuando una interfaz falla.
Una fábrica con maquinaria local no necesita automáticamente un ERP local.
MES, maquinaria, PLC, básculas, impresión de etiquetas o almacenes automáticos pueden tener requisitos de latencia y disponibilidad que deben resolverse localmente. Pero Business Central no tiene por qué ejecutar esas tareas. Puede actuar como sistema de gestión y recibir o enviar transacciones a través de una capa de integración.
El diseño híbrido correcto separa ejecución local de gestión central. Esto reduce el argumento de “necesitamos on-premise porque la fábrica debe seguir funcionando si cae Internet”, siempre que exista una estrategia clara de cola, sincronización, conflicto y reconciliación posterior.
Proceso local
Ejecución que debe responder en milisegundos, operar con equipos físicos o sobrevivir a una pérdida temporal de conectividad.
Proceso ERP
Órdenes, consumos, output, compras, inventario, coste, facturación, finanzas y trazabilidad empresarial.
Capa de integración
Colas, APIs, transformación, reintentos, observabilidad y gestión de mensajes para desacoplar ambos mundos.
Prueba obligatoria
Simular pérdida de conectividad y demostrar cómo sigue operando planta, cómo se recupera la sincronización y cómo se resuelven conflictos.
Una restricción regulatoria debe estar documentada. No basta con llamarla “compliance”.
Existen organizaciones con requisitos específicos de ubicación, aislamiento, sector público, seguridad nacional, export control o contratos que pueden limitar determinados servicios cloud. En esos casos, on-premise puede ser defendible.
Pero la decisión debe identificar exactamente qué norma, contrato o riesgo exige esa arquitectura, qué datos afecta y si Microsoft ofrece una región, certificación o configuración que pueda satisfacerlo. Convertir una preocupación genérica en requisito verificable evita mantener on-premise por una interpretación que ya no corresponde al entorno actual.
Cinco situaciones frecuentes y qué alternativa parte con ventaja
Empresa mediana que moderniza NAV
Quiere reducir infraestructura, actualizar tecnología, conectar Microsoft 365/Power BI y eliminar parte de la personalización histórica. Online parte con ventaja si la migración clasifica bien código y datos.
Grupo con varias sedes
Necesita acceso desde distintas ubicaciones, incorporar usuarios, crecer en sociedades y conectar herramientas cloud sin ampliar infraestructura local.
Industria con MES y sistemas de planta
La existencia de sistemas locales no obliga a on-premise. Debe validarse conectividad, operación offline, latencia y estrategia de integración antes de decidir.
Restricción regulatoria demostrable
Existe una obligación formal de aislamiento, residencia u operación que el servicio online disponible no puede cumplir.
On-Premise mantenido por inercia
Versión retrasada, infraestructura envejecida, conocimiento concentrado, backup no probado, personalizaciones poco documentadas y decisión de seguir local porque “siempre ha funcionado”. Este escenario necesita un business case de modernización aunque la migración no sea inmediata.
SaaS puede ser el destino correcto y el momento equivocado.
Una migración apresurada puede trasladar deuda, romper integraciones o crear una transición difícil de sostener. Si la compañía no ha inventariado código, no entiende sus datos o depende de una interfaz crítica sin alternativa, puede ser más sensato preparar primero la arquitectura.
La decisión no debe convertirse en “on-premise para siempre”. Puede plantearse una etapa de estabilización con fecha, entregables y condición de salida hacia online.
Código sin inventario
No sabes qué personalizaciones siguen usándose ni qué tablas/datos dependen de ellas.
Integración crítica sin plan
MES, WMS, EDI u otro sistema bloquea operación y todavía no existe una arquitectura destino validada.
Datos sin owner
La organización no puede decidir qué migrar, limpiar, archivar o reconciliar.
Cambio simultáneo excesivo
La empresa intenta cambiar ERP, procesos, almacén, CRM y planta al mismo tiempo sin capacidad de absorción.
Restricción temporal
Un contrato, regulación o dependencia desaparecerá pronto y conviene coordinar la transición.
Objetivo
Preparar migración con hitos concretos, no congelar la decisión indefinidamente.
Migrar a SaaS no es mover una base de datos. Es transformar el modelo de mantenimiento del ERP.
Microsoft dispone de herramientas de cloud migration para versiones soportadas de Business Central on-premises. En 2026, la documentación oficial indica que versiones on-premises 25 o posteriores pueden migrar directamente; versiones 15–24 deben actualizarse al menos a versión 25 antes de migrar. NAV requiere rutas previas de actualización.
Además, las personalizaciones deben estar gestionadas mediante extensiones compatibles. La migración técnica debe coordinar datos, compañías, usuarios, permisos, record links, integraciones, apps y cutover. El resultado final debe ser un entorno que pueda seguir actualizándose sin volver a depender del modelo anterior.
Si vienes de NAV, la decisión SaaS vs On-Premise es también una decisión sobre cuánto pasado quieres conservar.
Microsoft documenta rutas específicas desde Dynamics NAV a Business Central online. Versiones anteriores requieren pasos intermedios y conversión de personalizaciones C/AL a AL o una estrategia de reimplantación. Esto transforma la conversación: el problema no es solo dónde alojar Business Central, sino qué código y datos merecen sobrevivir.
Mantener on-premise como paso temporal puede ser razonable mientras se modernizan personalizaciones. Mantenerlo indefinidamente solo para no tomar esa decisión suele aumentar el coste del siguiente salto.
NAV 2015–2018
Microsoft documenta ruta a BC 14, después BC 25+ on-premises y finalmente Business Central online.
C/AL → AL
Las personalizaciones antiguas deben convertirse a extensiones o replantearse.
Reimplantación
Puede ser mejor cuando el modelo histórico arrastra demasiado código, datos y procesos obsoletos.
Histórico
Decidir qué debe migrarse al ERP y qué puede quedar accesible para consulta/analítica.
Integraciones
Sustituir accesos directos y tecnologías antiguas por APIs y patrones más sostenibles.
Resultado
Salir con un ERP actualizable, no con una copia cloud del NAV anterior.
El coste de on-premise no termina en servidores. Incluye lo que no haces porque mantener el ERP ocupa la capacidad disponible.
Si el equipo técnico dedica tiempo a backups, parches, upgrades, incidencias de infraestructura y compatibilidades, ese tiempo no está disponible para mejorar procesos, integración, automatización o datos. En organizaciones pequeñas, esta oportunidad perdida puede ser más relevante que el coste del hardware.
No todo mantenimiento es desperdicio: una empresa con necesidades específicas puede necesitarlo. La pregunta es si la organización quiere que esa capacidad siga siendo estratégica dentro de casa.
Horas IT
Operar plataforma, backups, actualizaciones, soporte, monitorización y capacidad.
Innovación diferida
Proyectos de automatización o datos que esperan porque la plataforma consume recursos.
Upgrade pendiente
Cada año de retraso puede aumentar incompatibilidades y conocimiento necesario para el siguiente salto.
Dependencia
Conocimiento concentrado en pocas personas o proveedores para mantener componentes históricos.
Velocidad
Tiempo para abrir nuevas sociedades, conectar procesos o desplegar capacidades modernas.
Decisión
Incluir oportunidad perdida en el business case, aunque no aparezca como factura.
Doce preguntas antes de mantener on-premise o aprobar una migración a SaaS
Diez formas de convertir una decisión de despliegue en deuda tecnológica
Elegir por costumbre
Mantener local porque siempre se hizo así, sin business case actualizado.
Elegir SaaS por moda
Migrar sin inventariar integraciones, datos o restricciones reales.
Confundir control con propiedad
Tener el servidor no significa tener mejor recuperación, seguridad o gobierno.
No calcular TCO
Comparar suscripción con hardware sin sumar soporte, SQL, personas y upgrades.
Posponer versiones
El control de calendario se convierte en años de deuda y un upgrade cada vez más caro.
Migrar toda la deuda
Copiar código, histórico y procesos sin valorar si siguen aportando valor.
No probar offline
Una fábrica adopta SaaS sin validar qué ocurre cuando pierde conectividad.
Sobrediseñar híbrido
Crear una arquitectura compleja para resolver una restricción que afectaba a un solo proceso.
Ignorar IA
Tomar una decisión a cinco años sin valorar Copilot, agentes y automatización futura.
No volver a revisar la decisión
Una razón válida para on-premise en 2026 puede dejar de existir. La arquitectura debe revisarse cuando cambian servicio, regulación, conectividad o estrategia.
La decisión SaaS vs On-Premise cruza ERP, infraestructura, seguridad, integración, datos y estrategia de IA
Ayesa puede evaluar Business Central desde una visión end-to-end Microsoft: ERP, Azure, Power Platform, Power BI, seguridad, datos e IA. Eso permite separar qué debe vivir en Business Central, qué puede permanecer local y qué arquitectura reduce riesgo y coste de evolución.
Profundiza según tu punto de partida
Dudas habituales sobre Business Central SaaS y On-Premise
¿Qué diferencia hay entre Business Central SaaS y On-Premise?
Cambian principalmente el modelo de operación, infraestructura, actualización y responsabilidad. SaaS es un servicio online operado por Microsoft; on-premise requiere operar y mantener la plataforma local o mediante un proveedor.
¿SaaS es siempre más barato?
No en cualquier fotografía puntual. La comparación debe hacerse a 3–5 años incluyendo infraestructura, SQL, soporte, actualizaciones, personal interno, continuidad y coste de oportunidad.
¿On-Premise ofrece más control?
Sí sobre infraestructura, versiones y componentes técnicos. Ese control implica también responsabilidad sobre seguridad, backup, recuperación, parches, disponibilidad y capacidad.
¿SaaS es más seguro?
No existe una respuesta automática. Microsoft opera la seguridad del servicio cloud, pero la empresa sigue gobernando identidades, permisos, datos e integraciones. En on-premise el cliente añade además seguridad de infraestructura y base de datos.
¿Se puede personalizar Business Central SaaS?
Sí. Business Central moderno utiliza extensiones y apps. El diseño debe ser compatible con el modelo continuo de actualización del servicio.
¿Copilot funciona en Business Central On-Premise?
No como capacidad nativa. Microsoft confirma que Copilot de Business Central es exclusivo de Business Central online.
¿Puede On-Premise conectarse con IA?
Sí mediante Azure AI, Copilot Studio u otros servicios, pero requiere una arquitectura propia de integración, identidad, permisos y mantenimiento.
¿Cada cuánto se actualiza Business Central online?
Microsoft organiza dos ciclos principales al año, en abril y octubre, además de actualizaciones menores durante el año.
¿Se pueden retrasar las actualizaciones en SaaS?
Los administradores pueden gestionar ventanas dentro del calendario ofrecido, pero el servicio está diseñado para mantenerse actualizado y no conservar indefinidamente una versión antigua.
¿Business Central On-Premise sigue soportado?
Sí, para versiones cubiertas por la política de ciclo de vida correspondiente. El cliente debe mantenerse dentro de las condiciones de soporte y aplicar actualizaciones requeridas.
¿Una fábrica puede utilizar Business Central SaaS?
Sí. Debe diseñarse bien la integración con MES, maquinaria, básculas, SGA, etiquetado y otros sistemas locales, incluyendo qué ocurre sin conectividad.
¿Necesito on-premise si tengo un MES local?
No necesariamente. Puede diseñarse una arquitectura híbrida donde el MES siga ejecutando localmente y Business Central online reciba las transacciones mediante integración.
¿Qué pasa si se cae Internet?
Los procesos que requieren operar durante una caída deben tener un diseño específico. En fabricación puede implicar ejecución local, colas y sincronización posterior.
¿Puedo migrar directamente cualquier Business Central On-Premise a online?
No. Microsoft mantiene rutas soportadas por versión. En 2026, versiones 25+ pueden migrar directamente; versiones 15–24 deben actualizarse primero al menos a 25.
¿Y si todavía utilizo Dynamics NAV?
Las versiones NAV requieren rutas previas de upgrade y conversión de personalizaciones. Microsoft documenta pasos intermedios distintos según versión.
¿Se migra todo el histórico?
No necesariamente. Conviene separar dato necesario para operar, histórico útil para consulta y datos que pueden archivarse o explotarse en otra capa analítica.
¿Qué pasa con usuarios y permisos durante la migración?
Microsoft indica que los usuarios y permisos on-premises no se migran automáticamente al tenant online; deben configurarse en el entorno Microsoft 365/Business Central de destino.
¿Se migran record links y notes automáticamente?
Microsoft documenta una tarea específica para completar su migración al finalizar el proceso cloud, por lo que deben incluirse en el checklist de cierre.
¿Cuándo tiene sentido mantener On-Premise?
Cuando existe una necesidad regulatoria, técnica, de conectividad, latencia o aislamiento que compensa de forma demostrable el coste y responsabilidad adicionales.
¿Cómo empiezo la decisión?
Inventariando versión, infraestructura, costes, personalizaciones, integraciones, continuidad, restricciones, roadmap de IA y TCO a 3–5 años.
No decidas dónde debe vivir el ERP hasta saber qué coste, riesgo y futuro estás comprando.
Podemos revisar versión actual, infraestructura, costes, soporte, personalizaciones, integraciones, continuidad, restricciones, Power Platform, datos e IA para construir una comparación SaaS vs On-Premise a tres y cinco años. El resultado debe dejar claro qué modelo tiene sentido, qué trabajo exige migrar y qué riesgo asumes si no cambias.
Hablemos de mantener On-Premise o pasar a Business Central SaaS
Indícanos qué versión utilizas, número de usuarios, infraestructura, personalizaciones, integraciones críticas, modelo de soporte y objetivos de evolución. Revisaremos primero el contexto y después el camino más defendible.