Business Central 2027 Release Wave 1: Say Goodbye to OData on Microsoft Pages
In the 2027 Wave 1 release of Business Central (version 30.0), Microsoft is retiring the option to expose Microsoft-authored pages as OData web service endpoints. This represents a significant shift in the integration strategy for the platform, as it pushes a stronger separation between the user interface (UI) and the application programming interface (API) layers.
From this point forward, only custom pages created by developers can still be exposed as OData endpoints, whereas Microsoft-owned pages, such as those in the Base Application, System Application, or other first-party apps, will no longer support this capability.
The reasoning behind this is the understanding that UI pages were never intended to act as stable APIs. Their design can and often does change with updates, which risks breaking integrations that depend on them. On top of that, using UI pages as OData endpoints has historically caused performance bottlenecks and stability issues. This also leads to inconsistent behavior because UI pages are optimized for human interaction, not for programmatic data consumption. By removing this option, Microsoft hopes to phase out fragile integrations and encourage adoption of more reliable alternatives, such as the standard APIs that Business Central now provides.
The transition is already happening. Starting with version 26 (2025 Wave 1), administrators see warnings whenever they try to expose Microsoft UI pages as OData endpoints. This has affected SOAP endpoints too: Version 26 blocks them by default through feature management, and they will be fully removed in version 29 (2026 Wave 2). The final phase arrives with version 30 in 2027, when OData support for Microsoft-authored pages will officially be gone.
For businesses, the takeaway is that waiting until 2027 to act is not an option. Any integrations that depend on OData page endpoints must be reviewed and migrated ahead of time. There are three steps with this activity:
- Identify which integrations are affected by auditing your web services and reviewing telemetry data for incoming OData requests.
- Decide whether you can fall back on standard APIs or whether you need to build a custom one. Business Central already provides a large catalog of well-documented, versioned APIs that are optimized for performance and reliability, and these should be your first choice.
- In cases where no standard API meets your requirements, you can create your own custom API page in AL code, designed specifically for the needs of your integration.
- Complete the migration by reconfiguring your existing integrations to point to the new endpoints and test them thoroughly.
For example, if your integration currently pulls data from an Item Card page, the process would involve creating an AL extension with a custom API page, copying over the relevant fields and logic from the Item Card, and then publishing the extension. Once deployed, you would point your integration at the new API, test the responses, and verify that the system continues to function correctly. This ensures that the integration works seamlessly before the 2027 changes take effect.
Businesses and partners relying on legacy OData endpoints should treat this as a priority project, as failing to migrate by 2027 will cause integrations to break and services to fail, leading to potentially severe business disruption. Starting early will ensure a smoother transition and minimize risk when the deadline arrives. This change marks a major evolution in Business Central’s integration model and reinforces Microsoft’s dedication to establishing APIs as the standard for connecting external systems.
To learn more about the deprecated features in the Business Central platform, refer to this release from Microsoft.
