Business Central v29 Removes SOAP Endpoints on Microsoft Pages

TL;DR

In Business Central version 29.0, exposing a Microsoft page as a SOAP endpoint will no longer be possible. Microsoft lists it as a removal, not a replacement (Microsoft Learn, deprecated platform features).

Version 29.0 is 2026 release wave 2, which runs October 2026 through March 2027. From 27 August that is roughly five weeks to inventory what breaks.

Microsoft's stated remedy is specific: "copy the source code for the page and host it in an extension/app." Your own pages are unaffected.

A second removal lands in the same version: on-premises deployments can no longer run data-defined permission sets only, because the UsePermissionSetsFromExtensions server parameter stops being honoured.

Microsoft's reasoning is worth quoting, because it explains the whole class: "A UI page isn't an API."

What exactly is being removed?

The ability to expose a Microsoft-authored page as a SOAP web service endpoint, removed in version 29.0, which ships in the wave that opens in October 2026, roughly 5 weeks from today. That is the whole change, and it is narrower and sharper than "SOAP is going away".

Microsoft's own wording, from the deprecated platform features list on Microsoft Learn:

"In version 29.0, exposing a Microsoft page as a SOAP endpoint will no longer be possible. If you need SOAP integrations for these pages, copy the source code for the page and host it in an extension/app."

Two things follow immediately. First, this is filed as Removed, not Replaced, so there is no drop-in successor to point an integration at. Second, the restriction is on Microsoft's pages. A page you or your partner authored in an extension is not covered by this line.

Why is Microsoft doing it?

Because a page was never an interface contract, and Microsoft says so plainly:

"A UI page isn't an API, so changes to them can happen in a release without being considered a breaking change. However, for customers who expose Microsoft UI pages as web service endpoints, a UI change can feel like a breaking change for an integration built on this endpoint."

That sentence is the most useful thing in the announcement. It describes a failure mode that has been quietly live for years: a customer publishes a Microsoft page as a web service, an integration is built on the shape of that page, Microsoft changes the page for ordinary UI reasons in an ordinary release, and the integration breaks with nobody having done anything wrong. Microsoft was free to change it. The customer was relying on it. Both were correct.

Removing the capability converts an unbounded future risk into one scheduled break. That is a better trade for everyone, and it is worth saying so rather than treating every deprecation as a tax.

It also lands in the same wave as the agent work. Business Central's 4 built-in finance agents arrived in wave 1, and agents now reach the ERP through MCP rather than through page-shaped endpoints. Retiring a UI page as an integration surface is part of the same move.

How much time is there?

Version 29.0 is 2026 release wave 2. Microsoft's wave 2 window runs October 2026 through March 2027.

Counting from 27 August 2026:

Milestone. Date. Time from today

Wave 2 window opens. October 2026. roughly **5 weeks**

Wave 2 window closes. March 2027. roughly **30 weeks**

Next stepping-stone release (v30). after v29. one full major cycle later

Five weeks is enough to find the problem and not always enough to fix it, which is the argument for doing the inventory before the remediation. The list of affected endpoints is knowable today; the effort to rebuild them is not, until you have the list.

What breaks, and what does not?

This is the distinction that decides how large the job is.

Situation. Affected by the v29 removal?

A Microsoft page published as a SOAP web service. **Yes.** This is the removal

A page you or your partner wrote, published as SOAP. No. Not a Microsoft page

An OData or API page endpoint. No. Different surface

A standard Business Central API (`/api/v2.0`). No

A Microsoft page copied into an extension and published from there. No. This is Microsoft's stated remedy

The remedy is a copy, not a rewrite. Copy the Microsoft page's source into your own extension, publish that as the SOAP endpoint, and the contract becomes yours to control. The integration on the other end does not need to know anything changed, which matters when the other end is a system you do not own.

That is also the honest catch. Once you copy the page, you own it. Microsoft's future improvements to that page stop reaching you, and the copy is now something your team maintains. Some of these endpoints will be better retired than copied, and the inventory is where you find out which.

What else is in version 29.0?

One more removal, and it only touches on-premises deployments.

Before 2021 release wave 1 (v18.0), system and extension permissions and entitlements were stored as data in the application database. From v18.0 they are defined in AL objects inside extensions. Through version 28.x, an on-premises customer could keep using data-defined permission sets only, by setting the server instance parameter UsePermissionSetsFromExtensions to false. From version 29.0 that capability is gone.

If you run Business Central on-premises and that parameter is set to false today, permission definitions have to move into extension AL objects before you take v29. Cloud tenants are not affected.

There is a rhythm worth knowing behind these lists. Microsoft cleans up fields marked ObsoleteState = Removed on a cadence of once every five major releases, at what it calls a stepping-stone release. The last was v25, so the next is v30. Version 29 is not a stepping-stone release, which means the two removals above are deliberate individual decisions rather than a scheduled sweep.

What should you do in the next five weeks?

Inventory first, remediate second. List every web service registered in your tenant, filter to SOAP, and split the list by whether the object is a Microsoft page or one of yours. Only the first group is in scope, and in most tenants it is a much shorter list than the first look suggests.

Ask what each endpoint is actually for. Some of these were built years ago for an integration that has since been replaced, and the cheapest remediation is deletion. An endpoint nobody calls is not a migration, it is a cleanup.

For the survivors, decide copy or replace. Copying the page into an extension preserves the contract and hands you the maintenance. Moving the integration to an API page or the standard API is more work now and less work forever. The right answer differs per endpoint, which is why the inventory has to come first.

On-premises: check the parameter. One command tells you whether UsePermissionSetsFromExtensions is false on your server instance. If it is, that work is separate from the SOAP work and has its own timeline.

FAQ

Is Microsoft removing SOAP from Business Central entirely?

No. The removal is specifically the ability to expose a Microsoft page as a SOAP endpoint. SOAP endpoints on your own extension pages are not part of this change.

Does this affect Business Central online, on-premises, or both?

The SOAP page removal is a platform change and applies to version 29.0. The permission-set removal is explicitly an on-premises concern.

What is the migration path Microsoft recommends?

Copy the source code for the page and host it in an extension or app, then expose that. Microsoft states this directly in the deprecation note.

When exactly does v29.0 arrive?

It is 2026 release wave 2, whose window Microsoft gives as October 2026 through March 2027. Check the release plan for the date that applies to your environment and update ring.

Is there any chance this slips?

Deprecations listed on the platform page have historically landed in the version stated. Plan for the stated version.

The last mile

Deprecations are ERP's most honest reminder that the system of record is a moving platform, not a fixed asset. Microsoft automates the removal and documents the remedy, and both are done well here.

What a schedule cannot tell you is which of your endpoints is worth carrying forward. That judgment sits in the same place as most ERP value: not in the data capture, but in the decision made on top of it, where somebody has to weigh what an integration costs against what it still earns. Turning a system of record into a system of intelligence is the layer Cognilium works in, and an upgrade inventory is a good, small example of the shape of the problem.