Blog
SOAP is retiring in Business Central: check your integrations before October
Deprecations rarely make headlines, but this one deserves a moment of your attention because it can break integrations silently. With Business Central 2026 release wave 2 (version 29, arriving in October) Microsoft removes the ability to publish its standard UI pages as SOAP web services. The switch that has let administrators keep those endpoints running is removed in the same update. After that, there is no rollback.
For a lot of organisations this is a non-event. For a few, it is the sort of thing that surfaces at the worst possible moment: a bank feed that stops, an EDI connection that goes quiet during a peak shipping week. The point of this post is to help you work out which camp you are in, well before October.
What is actually being retired
Let us be precise, because the scope matters and the internet is being loose about it.
- What goes: the ability to expose Microsoft’s own pages as SOAP endpoints. That means a page from any app published by Microsoft, which is broader than most people assume: the Base Application, the System Application and every first-party app. The capability is removed in version 29.
- What is not (yet) in scope: SOAP endpoints built on codeunits, and pages published from your own per-tenant extensions, the ones built specifically for your system. SOAP as a whole is still deprecated, but these have no confirmed removal date.
One detail is worth getting right before you go looking in the system, because it works backwards from what you would expect. Since version 26, standard pages have been blocked from SOAP by default, and the control is a Feature Management key called Disable SOAP web services on Microsoft UI pages. That key is switched on out of the box, and switching it off is what lets SOAP keep working. So if a standard-page SOAP integration still runs on your system today, somebody has already turned it off deliberately. In version 29 the key disappears, and the choice goes with it.
Where this bites in the real world
SOAP has been the plumbing behind a lot of quiet, long-running integrations. The ones we would worry about first are the revenue-critical and finance-critical ones:
- EDI connections with retail customers. A broken feed here is not only your inconvenience; with many retailers it triggers chargebacks.
- Bank reconciliation and treasury feeds. A failed feed can delay a period close by days.
- Warehouse, shipping and third-party logistics links that were wired up years ago and have simply worked ever since.
The insidious part is timing. These integrations often fail silently on upgrade and are only noticed at month-end, during a quarterly report, or in the middle of a busy dispatch week. That is the scenario worth spending an afternoon to avoid.
The good news: the alternatives are better anyway
Microsoft’s recommended path is to move to REST API web services. OData v4 is on the list too, but treat it carefully in this particular case: exposing a Microsoft page as an OData endpoint is itself being removed one release later, in version 30 (2027 release wave 1). Swapping a standard-page SOAP endpoint for a standard-page OData endpoint buys you about a year and then lands you back in this same conversation. If you have a per-tenant extension, copying the page into it and publishing from there stays supported.
So we steer clients to the API endpoints rather than a like-for-like OData swap, and that pending v30 change is the reason. The APIs are faster, more predictable, better documented, and they are where Microsoft is investing. In most cases this is less “emergency migration” and more “finally retiring a bit of technical debt that was overdue.”
How to find out whether you are affected
You do not have to guess, and you should not. There are two checks, and the first one takes minutes.
- Open the Web Services page in Business Central. It lists every published endpoint, the object type behind it, and whether SOAP is ticked. Page-type entries with SOAP enabled are your candidate list, and finding them needs no special tooling or licence.
- Then confirm what is actually being called, using web service telemetry. Where the environment sends telemetry to Application Insights, every call is logged with its endpoint type (API, OData or SOAP), the object behind it and enough detail to trace the caller. Since version 26 there is also a dedicated deprecated endpoint called signal that flags precisely these SOAP-on-standard-page calls. If nobody ever configured Application Insights, that history does not exist, and setting it up is worth doing on its own merits.
- Map each endpoint to a business process so you can rank by impact rather than by technical curiosity.
If nothing calls a standard page over SOAP, you can close this tab and get on with your day.
What we would do first
For clients with any meaningful integration estate, this is the order we would work in over the next few weeks:
- This month: produce a plain list of active SOAP endpoints, tagged by the process each one serves.
- Prioritise the money. EDI, bank feeds and shipments come first; internal reports and nice-to-haves come last.
- Rebuild against the API where you can, and use the per-tenant extension route only where a full rebuild cannot land in time.
- Test on version 29 before it reaches production. Preview environments are available around a month ahead of the October release, so nothing has to be discovered live.
- While you are in there, ask the question everyone skips: is this integration still needed at all, or has a standard connector caught up with what it does?
October is not far away, and this is the rare deprecation with no undo button. A couple of hours of checking now is a great deal cheaper than a broken feed during your next close.
Got an integration you inherited and cannot vouch for? Tell us your story and we will work out what it actually runs on.