Saltar al contenido 
En cada nueva versión de Business Central, Microsoft no solo añade funcionalidades. También revisa la arquitectura y descontinúa formas de trabajar que considera superadas. Algunas de esas decisiones pasan desapercibidas. Otras afectan a integraciones que llevan años funcionando en silencio y que nadie ha tocado porque nunca han dado problemas.
Este es el caso de los servicios web SOAP y OData sobre páginas de Microsoft. Una forma de conectar Business Central con otros sistemas, muy habitual durante años, que tiene fecha de retirada confirmada. El primer corte llega con la versión 29, prevista para octubre de 2026. El segundo, con la versión 30, en la primavera de 2027.
Si tu empresa tiene integraciones activas con Business Central, el momento de revisar qué está usando cada conexión es ahora, no cuando la actualización ya haya llegado al entorno.
¿Qué cambia exactamente y cuando?
La retirada se produce en dos fases, y entender bien el alcance de cada una evita actuar sobre lo que no hace falta y dejar sin revisar lo que sí importa.
Con la versión 29 (2026 release wave 2, disponibilidad general octubre de 2026) desaparece la posibilidad de publicar páginas de Microsoft como servicios web SOAP. Desde la versión 26 este comportamiento ya estaba desactivado por defecto, aunque podía reactivarse temporalmente desde la administración de características. Con la versión 29 esa opción desaparece por completo.
Con la versión 30 (2027 release wave 1, a partir de abril de 2027) llega el turno de OData. A partir de esa versión no será posible exponer como endpoint OData ninguna página cuyo editor sea Microsoft, lo que incluye Base Application, System Application y cualquier otra aplicación de primera parte de Microsoft.
Hay un matiz que conviene entender bien desde el principio. La retirada afecta exclusivamente a las páginas publicadas por Microsoft. Las páginas propias, desarrolladas por el partner o incluidas en una aplicación instalada con un editor diferente, podrán seguir publicándose como OData o SOAP.
Los codeunits expuestos como servicios web tampoco se ven afectados. El impacto es real, pero acotado. Depende de qué páginas concretas están usando las conexiones de cada entorno.
Por qué no basta con apuntar a una URL diferente
Para una integración que ya funciona, el cambio no se resuelve simplemente cambiando la dirección del servicio. Una página de Business Central y una API no exponen la misma información ni con la misma estructura. La página está diseñada para trabajar con ella desde el ERP. Una API, en cambio, está construida para que otro programa consuma datos de forma eficiente, controlada y sin depender de la lógica visual de la interfaz.
Imaginemos una tienda online conectada con Business Central. Mediante una integración se consultan los artículos, reciben líneas de pedido y aplican filtros y se sincroniza la información. Si esa conexión utiliza una página estándar publicada como OData, habrá que revisar qué campos está utilizando, qué filtros aplica y qué información necesita la tienda.
En la práctica, nos encontraremos ante estas situaciones:
- Existe una API estándar que proporciona los datos necesarios. La sustitución será relativamente fácil y directa.
- La API estándar no contiene toda la información necesaria. En este caso será necesario desarrollar una API a medida.
- Se trata de consultas de lectura con muchos registros. En determinados casos puede ser más adecuado utilizar una API query, es decir, una consulta que permite definir qué datos necesita una aplicación y devolverlos directamente desde Business Central sin depender de una página.
¿Qué conexiones pueden verse afectadas?
La respuesta es que cualquier aplicación que esté consultando una página de Microsoft publicada como servicio web puede verse afectada. Los casos más frecuentes son los informes y cuadros de mando de Power BI, las hojas de Excel conectadas en vivo, las tiendas online que sincronizan artículos y pedidos, los programas de almacén que consultan existencias, las plataformas EDI que recogen información de clientes o productos y las aplicaciones externas que integran datos de Business Central con otros sistemas.
El impacto concreto varía en cada caso. Algunas conexiones pasarán a una API estándar sin apenas trabajo. Otras necesitarán una API desarrollada a medida. Y algunas, al revisarlas, resultarán estar sin uso activo desde hace tiempo.
En entornos con años de historia es habitual encontrar integraciones desarrolladas por diferentes proveedores en momentos distintos, algunas de las cuales ya nadie recuerda con exactitud. Eso sí, el cambio que anuncia Microsoft obliga a hacer un inventario real de lo que hay, y eso en sí mismo tiene valor independientemente de los plazos.
Power BI, el principal afectado
Power BI es el caso que más preocupa en la mayoría de entornos, y con razón. Muchos cuadros de mando de Business Central se construyeron consultando páginas estándar publicadas como OData, y esas conexiones dejarán de funcionar con la versión 30 si no se migran antes. En Triangle podemos ayudarte a identificar qué consultas están obteniendo información mediante páginas de Business Central publicadas como servicio web y cuáles utilizan ya una API.
La alternativa que recomienda Microsoft es el conector API de Business Central, que trabaja directamente contra las API pages y API queries en lugar de contra las páginas de interfaz. Además de resolver el problema de compatibilidad, este enfoque tiene un beneficio de rendimiento concreto. Cuando un informe consulta grandes volúmenes de información a través de una página, Business Central tiene que procesar toda la lógica de esa página para devolver los registros. Con una API query configurada en modo solo lectura, el sistema puede dirigir las lecturas hacia una réplica secundaria y reducir la carga sobre la base de datos principal. Algunos cuadros de mando que hoy tardan en actualizarse pueden hacerlo notablemente más rápido después de la migración.
Para las hojas de Excel conectadas en vivo la situación es similar. Las conexiones que usan OData sobre páginas de Microsoft necesitarán revisar su origen de datos antes de que la versión 30 llegue al entorno.
Desde Triangle podemos ayudarte a determinar cuál es la mejor arquitectura para no penalizar el rendimiento de tu ERP y tus informes. Por ejemplo, para escenarios de lectura masiva pueden utilizarse API queries de solo lectura. Configuradas con acceso ReadOnly, Business Central puede dirigir las lecturas a una réplica secundaria cuando esté disponible, reduciendo así la carga sobre la base de datos principal.
Cómo saber qué está usando tu entorno ahora mismo
Muchas empresas no disponen de un inventario completo de las conexiones activas de Business Central. No es una crítica, es la realidad habitual de cualquier entorno que lleva años en producción y en el que han intervenido diferentes proveedores.
Business Central registra telemetría de todos los servicios web que recibe. Con Azure Application Insights activo en el entorno, es posible consultar esas llamadas mediante KQL y obtener un registro de qué tipo de servicio usa cada conexión: SOAP, OData V3, OData V4 o API. Desde la versión 26, además, Business Central genera una señal específica cada vez que se invoca un endpoint que ya ha sido marcado como deprecated, lo que permite localizar exactamente las conexiones que dejarán de funcionar cuando lleguen las versiones 29 y 30.
También es posible revisar directamente la página de servicios web publicados dentro del propio Business Central. En conexiones como Power BI, la revisión de los propios informes permite localizar de dónde obtiene los datos cada consulta.
A partir de ese inventario, cada conexión se estudia por separado. Las que tienen una API estándar equivalente tienen una sustitución más directa. Las que necesitan una API propia requieren desarrollo y pruebas con la aplicación que está al otro lado. Y las que ya no tienen uso real pueden retirarse, lo que simplifica el entorno y elimina puntos de acceso que nadie controla.
¿Cómo podemos ayudarte desde Triangle?
Para estar preparados para este cambio, en Triangle hemos preparado un estudio de arquitectura de APIs para identificar qué conexiones de cada entorno están afectadas y qué alternativa necesita cada una.
La revisión empieza por las llamadas que está recibiendo Business Central y continúa con las conexiones concretas, incluidos los informes de Power BI. El objetivo es localizar las dependencias de páginas de Business Central y determinar qué información necesita cada aplicación conectada.
El resultado se concreta en una relación de conexiones y actuaciones:
- Qué conexiones están afectadas por la retirada de SOAP;
- Cuáles dependen de OData;
- Qué APIs estándar pueden utilizarse como sustitución;
- Qué APIs propias habría que desarrollar;
- Qué consultas pueden resolverse mediante API queries;
- Qué conexiones ya no tienen uso y pueden eliminarse.
Esto permite conocer antes de empezar qué desarrollos hacen falta y cuáles requieren coordinación con otros proveedores. No todas las empresas tendrán el mismo número de conexiones ni necesitarán desarrollar las mismas APIs, por lo que el punto de partida tiene que ser el entorno real de cada una.
El calendario aprieta más de lo que parece
La versión 30 llega en la primavera de 2027. Todavía queda margen, pero las integraciones rara vez se pueden modificar desde una única plataforma. Si Business Central está conectado con una tienda online, un programa de almacén o una plataforma EDI, el cambio implica también al proveedor de esas aplicaciones, y coordinar ese trabajo lleva tiempo.
Hay otro factor que no siempre se tiene en cuenta. La versión 29, que retira SOAP, llega en octubre de 2026, mucho antes. Algunas conexiones SOAP llevan años funcionando sin que nadie las haya revisado porque nunca han dado problemas. Revisarlas con margen suficiente permite localizar las dependencias reales, ver si necesitan coordinación externa y planificar el proyecto sin que el plazo sea el que mande.
El primer paso no requiere empezar a migrar nada. Requiere saber qué hay.
Preguntas frecuentes
No de la misma forma. La retirada de SOAP y OData sobre páginas de Microsoft está vinculada a las versiones del producto, por lo que on-premises también se verá afectado cuando se actualice a las versiones 29 y 30. Sin embargo, los entornos on-premises tienen más control sobre el calendario de actualización que los entornos en la nube, donde Microsoft gestiona las actualizaciones automáticamente.
En cualquier caso, la recomendación de migrar a API pages y API queries aplica igualmente, aunque el conector API de Power BI y algunas funcionalidades de telemetría están orientadas principalmente a Business Central Online.
Las claves de acceso a servicios web, también conocidas como Web Service Access Keys, quedaron deprecadas para Business Central Online desde 2022 y ya no son una opción válida en entornos en la nube.
Si alguna integración todavía usa ese método de autenticación, el problema es previo a la retirada de SOAP y OData y requiere migrar primero a OAuth 2.0 con Microsoft Entra ID. En entornos on-premises las claves de acceso pueden seguir funcionando dependiendo de la versión y la configuración, pero no es una situación recomendable desde el punto de vista de seguridad.
Depende de cómo estén construidas. Si el flujo de Power Automate utiliza el conector estándar de Business Central, que trabaja ya contra las API v2.0, no hay impacto.
Si en cambio algún paso del flujo consulta directamente una página de Business Central publicada como servicio OData o SOAP, sí estará afectado y tendrá que actualizarse. Lo mismo aplica a los flujos de Azure Logic Apps que usen una conexión directa por URL al endpoint de un servicio web de Business Central.
No directamente. El servidor MCP de Business Central es una capa de acceso diseñada para agentes de inteligencia artificial, no un reemplazo de las integraciones máquina a máquina que hoy usan SOAP u OData.
Lo que sí es relevante es que el MCP Server se construye sobre las mismas API pages que Microsoft recomienda como destino de migración. Dicho de otro modo, migrar las integraciones a API pages resuelve el problema de compatibilidad con las versiones 29 y 30, y al mismo tiempo deja el entorno preparado para habilitar escenarios de IA sobre esos mismos datos cuando tenga sentido hacerlo.
Con SOAP, la versión 29 elimina definitivamente la posibilidad de publicar páginas de Microsoft por ese protocolo, así que cualquier conexión que dependa de ello dejará de funcionar en ese entorno tras la actualización. Con OData ocurre lo mismo en la versión 30.
Si la integración no se ha migrado a tiempo, se producirá un error en las llamadas y la aplicación conectada dejará de recibir datos o de poder operar. Por eso el inventario previo es tan importante: saber exactamente qué hay permite estimar el trabajo real y decidir si el ritmo de migración es compatible con el calendario de actualizaciones del entorno.
Microsoft retira en dos fases la publicación de páginas estándar como servicios SOAP y OData en Business Central. El primer corte llega en octubre de 2026 y el segundo en la primavera de 2027. Si tu entorno tiene integraciones activas con Power BI, Excel o aplicaciones externas, el momento de revisarlas es ahora.
Somos especialistas en Business Central. Si tienes integraciones activas y no sabes cuáles se verán afectadas, las revisamos y te decimos qué hay que cambiar y cuándo. Habla con nuestro equipo.
¿Sabes qué conexiones de Business Central dejarán de funcionar?
La retirada de SOAP y OData sobre páginas de Microsoft puede afectar a integraciones con Power BI, Excel, tiendas online, programas de almacén, EDI y otras aplicaciones. En Triangle revisamos las conexiones de tu entorno, identificamos cuáles están afectadas y definimos qué APIs necesita cada una.
Solicita una revisión de tus integraciones sin compromiso.
