Business Central 29 Removes SOAP on Microsoft Pages: The Integration Break UAT Will Not Catch

What version 29 actually removes

Microsoft's platform deprecation list is specific: in version 29.0, exposing a Microsoft page as a SOAP endpoint is no longer possible. The feature key named Disable SOAP web services on Microsoft UI pages goes with it, so the switch holding the door open disappears at the same moment the door does.

The scope is narrower than the headline suggests, and the boundary is what matters:

Microsoft's reasoning is explicitly stated: a UI page is not an API. Microsoft can change its own pages in any release without that counting as a breaking change, so every integration built on one as an endpoint has been sitting on a contract that was never a contract. The recommended replacements are the built-in REST APIs, OData V4, or a page you own.

Most of this already happened in v26

Coverage tends to present this as a change arriving with version 29. More accurately: it landed in 2025 release wave 1. Version 29 is when the escape hatch closes.

The deprecation was announced in 2024 release wave 1. In version 26.0 Microsoft shipped the feature key and switched it on by default, blocking the publishing of Microsoft UI pages as SOAP web services. To keep the capability, an administrator has to disable the key for all users. Version 29.0 removes that option.

Deferred work is rarely documented, and whoever disabled the key to unblock a go-live is often not whoever runs the upgrade.

Why a normal UAT pass will not find it

Most UAT scripts on a Business Central project are written from the user's seat: open the sales order, add the line, post it, check the value. That is the right way to write them, and exactly why this slips through.

A SOAP endpoint has no screen. Nothing looks different when it stops answering, because the page still works perfectly for the human in front of it. The failure surfaces where the script never goes: a warehouse app that stops writing back, an EDI feed that starts queueing, a bank import that returns nothing and is mistaken for a quiet day. Each has a business owner who would have flagged it instantly, had anyone put it in front of them.

This is the standing weakness of acceptance testing scoped purely to the application. The regression pass proves the system still behaves; not that it is still talking to anything. On a mature ERP estate, integrations are where the operational risk lives and the least tested part of the environment.

What to test, and where to test it

Update 29.0 is in public preview ahead of general availability, and a preview sandbox is where an upgrade regression pass belongs. Same argument as when the release wave calendar disappeared: anchor testing to the version train, not the announcements.

Inventory first, test second. Before writing a case, list the published web services per tenant and mark which are SOAP, which sit on Microsoft pages, and whether the feature key has been disabled. That answers whether you have a problem at all — on most tenants, no.

Add integration cases, with named owners. Not a developer smoke test: a case owned by whoever notices when the feed is wrong. "Yesterday's EDI orders appear in the order list by 09:00" is a UAT case, with an owner, an expected result and a pass or fail. It is the only kind that catches this.

Test the consumer, not the endpoint. Confirming a SOAP URL still responds proves less than running the partner system against it; integrations fail at the boundary far more often than in the middle. Our Business Central UAT guide covers structuring that scope.

Treat remediation as a project, not a toggle. Replicating a Microsoft page into a per-tenant extension is the quickest route back to working, but it is a development change with its own test cycle, and leaves you owning a copy of a page Microsoft keeps improving. The REST APIs cost more now and less later.

A partner who can produce that inventory and a dated plan is selling upgrade assurance. One who finds out on go-live morning is absorbing the cost of it.