Every Business Central partner with a client list has spent the last few months triaging one deadline: SOAP web services on Microsoft-authored pages stop working the moment version 29.0 goes generally available on October 1, 2026. It’s a real cutoff, it’s close, and it deserves the attention it’s getting. But teams that treat that project as the finish line are missing the bigger one sitting six months behind it. Business Central’s OData deprecation for Microsoft UI pages lands with version 30.0, the 2027 release wave 1 release scheduled for the first workday of April 2027, and it is going to break far more integrations than SOAP ever did, because OData has been the default, path-of-least-resistance protocol for Business Central reporting since NAV migrated to the cloud.
Here’s the scenario that shows up in almost every environment once you actually go looking: a controller built an Excel workbook years ago that pulls G/L entries through an OData feed on a standard Microsoft page. Nobody remembers who set it up. It isn’t in the integration inventory because nobody classified a spreadsheet as an integration. A Power BI dataset does the same thing against the Customer or Item Ledger Entry pages, refreshing nightly through a service account that predates the current IT team. None of this shows up when you audit “our integrations,” because the people who’d know to look for it moved on, and the connections themselves were never registered anywhere except a connection string buried in a Power Query step. SOAP, by contrast, was mostly used by a smaller set of legacy middleware tools that companies have already been migrating off for years because SOAP has felt dated since well before Microsoft announced its removal. OData never felt dated. It’s still the protocol Microsoft’s own documentation recommends for ad hoc reporting scenarios, right up until version 30 removes the ability to expose a Microsoft-authored page through it at all.
What Business Central’s OData deprecation actually removes
The scope here matters, because it’s narrower than the headlines suggest and that narrowness is exactly what makes it easy to underestimate. Starting in version 30, Business Central will no longer allow a page published by a Microsoft-authored app, meaning the Base Application, System Application, or any other first-party extension, to be exposed as an OData endpoint. Custom pages you or a partner built in your own AL extension are unaffected. Standard API pages and API queries, which already use a different endpoint structure under /api/v2.0/, are unaffected. What goes away is specifically OData access to the UI pages Microsoft ships out of the box: the Customer Card, the Chart of Accounts, the Sales Order list, and every other page that a reporting tool or Excel workbook has been happily pointing at for a decade.
Microsoft’s stated rationale is worth understanding because it explains why there’s no reprieve coming. A UI page isn’t governed by the same change-management discipline as an API. Microsoft can add a field, reorder a FastTab, or rename a control on a standard page in a minor update without that counting as a breaking change to the platform, but if your OData integration depends on that page’s exact shape, the same update breaks your feed. Microsoft has effectively decided it can no longer support that implicit contract at scale, and the SOAP removal in version 29 was the first half of enforcing that decision. Version 30 finishes it for OData.
Finding what you don’t know is there
Before any migration plan makes sense, you need an honest inventory, and guessing from documentation or asking the client “what connects to BC” will undercount every time. Business Central’s telemetry to Application Insights already logs this if you have it wired up. Web service requests are recorded under event ID RT0008, and the category custom dimension on that event records whether each call came in as API, ODataV4, ODataV3, or SOAP. Paired with the alObjectName and endpoint dimensions, a straightforward Kusto query against your Application Insights workspace, filtering customDimensions.eventId == "RT0008" and grouping by category and object name, will produce a real list of which Microsoft pages are being called through OData, how often, and from what client. Run that query across a full month rather than a day or two; monthly reports and quarter-end reconciliation jobs won’t show up in a short window, and those are exactly the integrations most likely to have been forgotten.
Triaging what the audit finds
Once you have the list, not every entry needs the same fix, and treating them uniformly wastes effort on the easy ones while under-resourcing the hard ones. Some OData calls map directly onto an existing standard API entity: Customer, Vendor, Item, and Sales Order OData feeds usually have a clean equivalent already published under API v2.0, and switching the connection string plus adjusting field names is genuinely a low-effort change. Others don’t have a standard API match because they’re pulling something specific, like a custom-shaped join across ledger entries and dimensions that a spreadsheet author built by hand in Power Query. For those, an AL query object is usually the right tool rather than trying to force a page-based API to do the work. Query objects are read-only, they can join across multiple tables the way the old OData feed effectively did through Power Query, and they publish as their own API endpoint with proper OData-style $filter and $select support, without exposing a Microsoft UI page at all. A third category is the genuinely awkward one: integrations built around unbound actions on standard pages, which as of now have no direct equivalent in the REST API surface. Microsoft hasn’t closed this gap yet, so the practical workaround is either wrapping the needed logic in a bound action on a custom API page you control, or moving that piece of orchestration out of Business Central entirely into an Azure Function or a Logic Apps flow that calls the standard API for the parts it can and handles the rest itself.
The option nobody should default to, but should know exists
If a specific OData integration truly cannot be replatformed before April 2027, Microsoft’s own guidance leaves one path open: copy the source code of the standard page into your own extension and publish that copy as the OData endpoint instead. This works because the restriction is specifically on pages published by a Microsoft-authored app, not on OData as a protocol. It should be treated as a last resort rather than a template, though, because it means you now own maintaining a forked copy of a Microsoft page indefinitely, including replicating any future field or logic changes Microsoft makes to the original. For a page that rarely changes, that’s a manageable trade-off for another year or two of runway. For a page tied to core financial posting, it’s a maintenance burden that will outlast the convenience it buys.
Building the plan now
Version 29’s SOAP removal is close enough that most partners already have a project underway for it, and there’s real value in doing the OData audit at the same time rather than as a separate engagement six months from now. The RT0008 telemetry query doesn’t distinguish urgency by protocol, so pulling both SOAP and OData usage in one pass gives you a single, complete picture of every legacy web service dependency in an environment instead of two half-finished ones. Clients who hear “we already checked your integrations for the SOAP deadline” and then get surprised by an OData outage eighteen months later will reasonably ask why the first audit didn’t catch it. It’s a fair question, and the honest answer is that it’s a different telemetry filter and a few extra hours of query classification, not a fundamentally different project. Doing both now, while the environment’s already open on the workbench, is the cheaper version of this work by a wide margin.
Routeget Technologies has been walking clients through Business Central’s SOAP and OData retirement timelines as part of standard health-check engagements, building the telemetry-based inventory first so the migration scope is based on what’s actually running rather than what’s documented.
#BusinessCentralOData #ODataDeprecation #APIv2Migration #BCIntegrations #ERPGovernance #BusinessCentralAPI
No comment yet, add your voice below!