Business Central 29 removes SOAP on Microsoft's own pages

Business Central version 29 — 2026 release wave 2 — removes the ability to publish Microsoft's own UI pages as SOAP web services, and removes the feature key that currently lets you turn that capability back on.

What it does not do is remove SOAP from Business Central, which is how a good deal of the coverage reads. The distinction decides whether this is a migration project or a scoped change, so it is worth getting right before anyone budgets for it.

What Microsoft actually committed to, and what it merely signalled

There are two statements on the same page and they are not the same kind of statement.

The dated one:

“Support for publishing Microsoft UI pages as SOAP web services will be removed in Business Central 2026 release wave 2 (version 29.0). Starting in version 26.0, Microsoft UI pages can't be published as SOAP web services unless the Feature: Disable SOAP web services on Microsoft UI pages key in Feature Management is turned off.”

The undated one, in the same note:

“Support for SOAP endpoints is deprecated in Business Central and will be removed in an upcoming release.”

One names a version. The other names no version and no date. Both are real, and they should be planned against differently: version 29 is a deadline, the broader removal is a direction. Treating the second as if it had version 29's date will cost you a project you did not need to run this year; ignoring it will cost you the same project twice.

The feature key is a double negative, and people will get it backwards

The escape hatch that has existed since version 26 is a Feature Management key named Disable SOAP web services on Microsoft UI pages. Microsoft:

“By default, this key is enabled for all users, preventing the publishing of Microsoft UI pages as SOAP web services. To enable this capability, disable the key for all users.”

Read that twice, because it will come up in a change conversation. The key being on means the capability is off. "We've enabled the SOAP feature key" almost certainly means SOAP is blocked. If you are relying on someone's verbal report of the key's state, ask what they mean rather than what the key is set to.

And the key goes with the capability: “The Disable SOAP web services on Microsoft UI pages feature key will be removed in Business Central version 29.0, when support for exposing Microsoft UI pages as SOAP web services is removed.” The temporary reprieve and the thing it reprieves disappear together, which is the correct design and worth stating so nobody plans on the key surviving.

Microsoft's own third option tells you the real scope

Microsoft lists three migration paths. Two are unsurprising — use the built-in APIs, or use OData V4. The third is the informative one:

“Replicate the Microsoft UI pages as page objects in per-tenant extensions, and publish the extension pages as SOAP web services.”

Microsoft is suggesting you keep using SOAP. That single sentence settles the scope question more clearly than any headline: version 29 removes SOAP on Microsoft's pages, not SOAP. If an integration must stay on SOAP — an EDI hub, a bank file exchange, a warehouse device, a reporting tool nobody will rewrite this year — there is a supported path that does not require rebuilding the consumer.

Update, September 18, 2026: the second of Microsoft's three paths — OData V4 — is not a durable substitute for SOAP on a Microsoft page. Microsoft's separate deprecation page for the platform states that in 2027 release wave 1 (version 30), “it's no longer possible to expose a Microsoft page as an OData endpoint” — the same restriction, one wave later. Microsoft's stated reason for the OData removal echoes the SOAP one, worded slightly differently: “A UI page isn't an API and therefore changes to them can happen in a release without this being considered a breaking change.” The scope is broad: “this change is relevant for any page from any app with the publisher Microsoft (for example, Base Application, System Application, every first party app).” Swapping SOAP for OData on the same Microsoft page buys one release, not a fix. The two paths that survive both removals are API pages and queries, or Microsoft's own workaround for this second removal, the same instruction in substance as the SOAP one: “you need to copy the source code for the page and host the page in an extension/app.” OData against a page you already host in your own extension is unaffected by either change — this is specifically about OData on Microsoft's pages.

It is not free. Replicating a standard page as an extension object is real work and real ongoing maintenance, and Microsoft's actual recommendation remains API pages and queries because they are optimised for the job. But it is the difference between "we must rewrite the integration by October" and "we can decide when to rewrite it".

Why Microsoft prefers API pages, and why that matters to the estimate

Microsoft's recommendation is not neutral between the options. Its guidance says to use API pages or API queries rather than exposing UI pages at all, “because they've been optimized for this scenario”, and points at its own performance guidance for writing efficient web services.

This next part is our read. The reason that matters commercially is that a UI page is a user interface object doing a machine's job. It carries the page's logic, its triggers and its field-level behavior, all executed per call. An API page is built for the traffic. So the migration that looks like the most work — moving to API pages rather than swapping SOAP for OData on the same page, a swap that (see the update above) only survives one more release anyway — is frequently the one that ends the recurring performance complaints nobody had connected to the integration.

That is worth saying out loud when the change is scoped, because "replace like with like" is the cheapest option on the estimate and the one most likely to be re-done within two years. If an integration is already slow, this deadline is the budget you were not going to get otherwise.

Find the callers before you scope anything

These integrations are typically the oldest things touching the ERP, and the person who built them frequently no longer works there. Microsoft points at the right instrument rather than asking you to guess:

“If SOAP web services are allowed (feature key disabled), use incoming web services request telemetry to monitor calls to deprecated SOAP endpoints.”

⚠️ Note the condition attached to that. The telemetry advice applies when SOAP is currently allowed. If the feature key is in its default state — capability blocked — then Microsoft UI pages are already not being served as SOAP in your environment, and the honest conclusion is that this change has already happened to you and nothing broke. That is a perfectly good finding, and it takes one check to reach.

What we would do first

• Check the feature key state, and say the answer carefully. Key enabled means SOAP on Microsoft pages is blocked. If it is in default state, you are likely already unaffected.
• If the key has been disabled to allow SOAP, pull the web services telemetry. You want a list of callers, not a list of published endpoints — the two are very different sizes.
• Separate Microsoft pages from your own. Only the first group has a version 29 deadline. Sorting the list this way usually shrinks the problem substantially.
• Do not let "SOAP is being removed" enter a budget conversation unqualified. The dated removal is narrow. The broad one has no date, and a vendor quoting one is worth asking to show the source.

Update, September 2026: 28.5 is out, and the v29 preview sandbox clock is real

Two follow-up facts for anyone testing against this deadline right now. First, for shops still on 2026 release wave 1 (28.x): Microsoft's release notes list an update 28.5 for Business Central 2026 release wave 1, dated only to September 2026 — Application Build 28.5.54151, Platform Build 28.0.54016. Microsoft's table gives a month, not a day; anyone quoting a specific September date for 28.5 is adding precision the release notes do not carry.

Second, and this one is worth acting on if a SOAP-to-API rework is being tested in a version 29 preview sandbox: Microsoft's own what's-new page for release wave 2 states that “Microsoft automatically deletes preview sandbox environments 30 days after update 29.0 becomes generally available—sometime in early November 2026. You can’t update a preview environment to a different version.” If the migration testing — the API-page conversion, the telemetry validation, the sign-off evidence — lives only in that sandbox, it disappears on Microsoft's clock, not yours. Keep test scripts, results, and any audit evidence somewhere durable before that window closes.

⚠️ Don't conflate these two clocks. The same release-wave-2 page also notes that “Features are no longer linked to release plans” — which reflects Microsoft no longer publishing Release Plans from September 2026, a change in how Microsoft documents features. It has nothing to do with when your tenant is serviced. Business Central's on-premises servicing waves are a separate schedule entirely (see Business Central on-premises servicing); do not read this documentation change as a signal about servicing timing.

For on-premises customers still on 28.x, 28.5 is now the concrete build to plan an upgrade path against.

Update, September 18, 2026: the OData path off Microsoft pages closes too, one release later

One correction to the migration-options guidance above, because it changes what "moved to OData" is worth. Microsoft's deprecation page for the platform lists, under Changes in 2027 release wave 1 (version 30.0): “Starting in version 30, it's no longer possible to expose a Microsoft page as an OData endpoint. A Microsoft page is a page that is created in an app with the publisher Microsoft. Therefore, this change is relevant for any page from any app with the publisher Microsoft (for example, Base Application, System Application, every first party app). If you need to have OData integrations to these pages, you need to copy the source code for the page and host the page in an extension/app.”

Read that against version 29's SOAP removal and the pattern matches — the same instruction in substance, worded slightly differently each time. Version 29's instruction: “copy the source code for the page and host it in an extension/app.” Version 30's: “you need to copy the source code for the page and host the page in an extension/app.” Same idea, one release later. So if the version 29 fix for a Microsoft-page integration was “switch it from SOAP to OData V4 and move on,” that fix has a shelf life of one release — 2027 release wave 1 removes OData on those pages too. Of Microsoft's three migration paths, only two survive both changes: the built-in API pages and queries, or copying the page's source into your own per-tenant extension. OData against pages you already host in your own extension is untouched by either removal; this is specifically about OData on Microsoft's pages. We are not stating a general-availability date for version 30 — Microsoft names the wave, 2027 release wave 1, not a day.

Sources

Quotations are from two Microsoft Learn pages, both read in full on September 5, 2026: SOAP Web Services (updated_at 2025-05-07) and Disable SOAP web services on Microsoft UI pages feature key (ms.date 2025-03-26, marked as applying to v26 and later).

The September 2026 update above draws on two further Microsoft sources, both read in full on September 13, 2026: Released updates for Business Central 2026 release wave 1 (update 28.5 table entry) and What's new in Business Central 2026 release wave 2 (version 29.0) (ms.date 2026-09-07).

The September 18, 2026 OData update above draws on a third Microsoft Learn source, read in full that day: Deprecated features in the platform (updated_at 2026-08-18).

⛔ One thing we deliberately have not written: a Business Central on-premises date for this change. Microsoft's pages give a version, not separate online and on-premises timing, and we do not publish dates we cannot source. Separately, the servicing clock for Business Central on-premises is a different matter with its own dates, and is unaffected by this.

If you would rather have the telemetry pull, the Microsoft-versus-custom page split and the migration decision handled as a bounded piece of work, scope it with us.