SOAP Web Services Are Going Away in Business Central: Your OData & API Migration Guide

If your Business Central environment integrates with anything — a webshop, a warehouse scanner, a bank feed, a Power BI refresh, a legacy EDI pipeline — there’s a very good chance part of it is running on technology Microsoft is actively retiring. Not in some vague future. The first step has already landed: version 29, released in October 2026, removed SOAP on Microsoft pages.

Two integration surfaces that have carried Business Central (and before it, NAV) for two decades are being switched off:

1. SOAP web services exposed on Microsoft-authored UI pages — removed in version 29, released October 2026. An environment still on version 28 keeps the old behaviour until it is updated; Microsoft’s update period for a major version runs five months from release, followed by a one-month grace period.
2. Page-based OData endpoints on Microsoft pages — removed in version 30 (2027 Wave 1).

This isn’t a licensing change or a cosmetic deprecation. If an integration still calls these endpoints once the environment runs the version that removes them, it stops working. No warning banner in your app. No graceful degradation. It just fails.

This article is the practical migration guide: what’s being retired and when, how to find every affected integration in your environment, what to replace it with, and a phase-by-phase plan that won’t disrupt your month-end close.

What’s Being Retired — And When

Microsoft has been signalling this move for years. The concrete timeline is now locked in.

The Two Legacy Surfaces

Business Central has historically exposed two integration surfaces that predate the cloud:

SOAP web services — the XML-based protocol inherited from Dynamics NAV. SOAP endpoints are synchronous, stateful, and impose heavy XML parsing overhead. They scale poorly under concurrent load, and they were designed for an era of tightly-coupled on-premise integrations.

Page-based OData — exposing UI page objects directly as REST endpoints. The problem: page-based OData runs the UI logic on every call. Field visibility rules, FlowFields, and page triggers all execute. It’s slow, fragile, and leaks UI behaviour into what should be a clean machine-to-machine contract.

Both are being replaced by a purpose-built API tier: the REST API v2.0 for common entities, and custom API pages/queries written in AL for everything else. These are decoupled from the UI, versioned explicitly, and designed for machine-to-machine communication.

The Deprecation Timeline

The key nuance most people miss: SOAP is not dying all at once. The version 29 removal only applies to SOAP endpoints exposed on standard, Microsoft-authored UI pages. If you built a SOAP endpoint on a codeunit or on your own per-tenant extension page, version 29 doesn’t remove it.

But don’t take false comfort from that. SOAP as a whole has been deprecated since Business Central 2021 Wave 1, and Microsoft has made clear it will be removed entirely eventually. Treat every remaining SOAP integration as a migration candidate, regardless of the specific deadline.

What Breaks (And What Doesn’t)

The most expensive mistake is assuming “we don’t use SOAP” without checking. Most teams don’t know what their integrations run on — the integrations were built years ago, by a partner who’s no longer around, or by an ISV add-on that “just works.”

Definite Breaks

• Any SOAP call against a standard Microsoft page (Customer Card, Sales Order, Item, Vendor, etc.) — fails once the environment is on version 29.
• Any OData v4 call against a standard Microsoft page — fails once the environment is on version 30 (2027 release wave 1).
• Anything published in Settings → Web Services with Type = Page and a SOAP or OData URL pointing at a Microsoft object.

What Keeps Working

• REST API v2.0 endpoints (/api/v2.0/...) — this is the recommended replacement and is actively expanded every wave.
• Custom API pages/queries you’ve written in AL — the direct replacement for page-based OData.
• OData on custom (non-Microsoft) pages — still works after v30, though Microsoft recommends migrating anyway.
• SOAP on codeunits or per-tenant extension pages — survives version 29, but plan to retire it too.

The Unbound Actions Gap

Here’s a genuine gotcha. Unbound Actions — AL actions not tied to a specific record — can currently only be called through OData. They have no equivalent in the REST API v2.0 surface yet. If you have an integration that triggers an unbound action over OData, there is no clean REST replacement today. You’ll need to either:

1. Re-architect the action as a bound action (tied to a record, which REST does support), or
2. Expose it through a custom API page or codeunit with a REST-friendly shape, or
3. Keep a thin OData shim on a custom page specifically for that action until Microsoft closes the gap.

This is exactly the kind of edge case a migration audit should surface early, not discover at cutover.

Step 1: Audit — Find Every Affected Integration

Before writing a single line of code, you need a complete inventory. This is the step everyone skips, and it’s the step that determines whether your migration is boring or a fire drill.

1a. The Web Services Page

Search → Web Services

This lists every published endpoint. Two things to do immediately:

1. Filter for Type = Page. Every entry here with a SOAP or OData URL is at risk. That list is your migration backlog.
2. Check the “Published” flag and the object type. If the object is a Microsoft page (you can tell by the object ID range and name), it’s subject to the deadlines. If it’s a custom extension page, it survives — for now.

Don’t just eyeball it. Export the list. You’re going to map each entry to the consuming system.

1b. RT0053 Telemetry — The Truth About What’s Actually Called

The Web Services page shows what’s published. It does not show what’s actually being called. That’s a critical distinction. You may have ten published endpoints, but only three are still used — or conversely, an integration may be hitting an endpoint you forgot was even published.

The RT0053 telemetry signal in Application Insights shows you every external call hitting deprecated endpoints. This is your single best source of truth for what’s actually live.

Enable Application Insights on your environment (Admin Center → Environment → Telemetry)
→ Look for signal RT0053 in the logs
→ It identifies every call to a deprecated SOAP or page-based OData endpoint

Run this across all environments — production, sandboxes, everything. If you don’t have Application Insights configured, that’s your actual first step. You will be surprised at what you find. In our experience, roughly a third of “active” integrations in a typical mid-market tenant are actually dead — but nobody noticed because the integration silently failed and a human was manually fixing the fallout.

1c. Map Each Endpoint to Its Consumer

For every affected endpoint, fill in:

• What system calls it? (webshop, WMS, reporting tool, legacy app, partner system)
• Who owns that system? (internal IT, an ISV, a third-party)
• How often and when? (real-time, nightly batch, monthly)
• What’s the impact if it breaks? (revenue process, reporting, nice-to-have)

Sort the list by impact. The EDI order intake that stops sales if it breaks goes to the top. The monthly internal report that nobody reads goes to the bottom.

Step 2: Classify — Simple Swap, Custom Build, or Re-Architect

Not all integrations are equal. Sort your discovered endpoints into three buckets. This determines your effort and cost.

Bucket 1: Simple Swaps (no AL work)

The entity already has a direct Standard API v2.0 equivalent. Customers, items, vendors, sales orders, purchase orders — the core entities are all covered.

• Action: change the integration’s endpoint URL from the legacy OData/SOAP URL to the REST v2.0 equivalent.
• Example: /ODataV4/Company('CRONUS')/Customer → /api/v2.0/companies({id})/customers
• Effort: hours to a day per endpoint, plus testing.

Bucket 2: Custom API Pages (AL work, bounded)

The data or process doesn’t exist in Standard v2.0 — custom tables, computed values, complex business logic.

• Action: write an APIPage (or APIQuery for read-only reporting) in AL exposing only the fields the integration actually consumes.
• Design principle: do not copy the structure of the UI page. Design the API for its actual consumers. Explicit field selection, no FlowField recalculation overhead, versioned routing.
• Effort: typically 2–10 consulting days depending on complexity.

Bucket 3: Re-Architect (the “replace polling with events” bucket)

The integration polls an OData endpoint on a schedule, or relies on synchronous SOAP in a way that doesn’t translate cleanly.

• Action: replace polling with webhooks (event-driven, push-based), or rework the process flow.
• Effort: varies widely — from days to a full mini-project.

This is also the opportunity to add things that were painful before: computed fields that previously required FlowField recalculation, proper versioning, better error handling.

Step 3: The Migration Path (Phase by Phase)

Here’s the sequence we run with clients. It’s designed so you’re never in a position where a broken integration blocks the business.

Phase 1 — Audit & Classify (Week 1)

• Export the Web Services list.
• Enable Application Insights and capture RT0053 data for at least a few days.
• Map every endpoint to its consumer and classify into the three buckets.
• Deliverable: a migration backlog, sorted by business impact.

Your role: name the integration owners and confirm which systems are still live. What we handle: the technical audit, telemetry setup, and classification.

Phase 2 — Quick Wins (Weeks 1–3)

• Migrate all Bucket 1 (simple swaps) to REST v2.0.
• Test in sandbox, then production, one endpoint at a time.
• Deliverable: the majority of your integrations moved with minimal effort.

Your role: coordinate testing with the teams that use each system. What we handle: the endpoint rewrites and testing harnesses.

Phase 3 — Custom Builds (Weeks 2–6, in parallel)

• Write custom API pages for Bucket 2 gaps.
• Expose only the fields actually consumed.
• Version from day one — publish v1.0, and when requirements change, publish v1.1 alongside it so consumers migrate on their own schedule.
• Deliverable: the long-tail integrations rebuilt on the modern surface.

Your role: sign off on field lists and approve the API contract. What we handle: the AL development, versioning, and deployment.

Phase 4 — Re-Architecture (Weeks 4–8+)

• Replace polling with webhooks for Bucket 3.
• Configure dead-letter queues and alerting (alert on dead-letter depth > 0).
• Re-architect unbound actions if needed.
• Deliverable: event-driven integrations that are more reliable than what they replaced.

Phase 5 — Deprecate & Validate (Final 1–2 weeks)

• Once consumers are migrated and stable, remove the old web service registrations in Business Central. This eliminates the deprecation warnings from the admin centre.
• Run the new integrations under realistic load in sandbox. Use Application Insights to confirm you’re operating well inside the 6,000 requests / 5-minute rate limit window.
• Deliverable: a clean environment with no deprecation warnings and validated rate-limit headroom.

What This Costs (Honest Numbers)

Integration migration pricing is driven by three things: how many endpoints, how complex the gaps, and whether you need re-architecture. Here’s the real range.

The big variable is usually discovery — how many integrations exist that nobody documented. A company that kept a clean integration inventory can migrate for €3,000–7,000. A company discovering a dozen undocumented legacy integrations mid-audit can realistically land at €20,000+.

Compare that against the cost of not migrating: an EDI order intake that silently stops after the version 29 update means you’re not receiving orders and don’t know why. For a distribution business, a single day of missed order intake dwarfs the entire migration budget.

Licensing note: none of this requires additional Business Central licenses. The REST API v2.0 and custom API pages are included in your existing subscription. You may need Copilot credits or Power Platform licensing only if you’re also building AI agents on top — that’s a separate project.

Team & Roles

A migration this cross-cutting needs a few named people, not a committee.

The single biggest success factor: one named owner who can say “yes, that system is dead, remove it” or “no, that runs payroll, don’t touch it.” Migrations stall when nobody has the authority to deprecate a legacy integration.

What Nobody Tells You

Three patterns we see in real migrations that the Microsoft docs don’t cover.

1. A third of your “integrations” are already dead. The RT0053 audit will show endpoints being called that map to systems retired years ago. Nobody cleaned them up. Don’t migrate a corpse — just remove the registration.

2. The undocumented one is the dangerous one. The integration that breaks you is rarely the one in the wiki. It’s the one an employee built in 2019 with a scheduled task on a PC that’s since been replaced, that quietly retried forever until it became “someone’s manual job.” Audit telemetry, not documentation.

3. SOAP retirement is a forcing function for good hygiene. The companies that treat this as “replace SOAP with REST, done” miss the real win. The companies that use it to kill polling, add versioning, and clean up ten years of technical debt end up with integrations that are genuinely more reliable than before. The deadline is annoying. The cleanup is worth it.

Checklist

Copy this. Work it top to bottom.

• Export the full list from Settings → Web Services
• Flag every entry with Type = Page (both SOAP and OData URLs)
• Enable Application Insights and capture RT0053 telemetry for 3+ days
• Map every affected endpoint to its consuming system and owner
• Classify each endpoint: simple swap / custom build / re-architect
• Sort the backlog by business impact (revenue processes first)
• Migrate simple swaps to REST API v2.0 (Bucket 1)
• Write custom API pages/queries for gaps — expose only consumed fields
• Version every new API from day one
• Replace schedule-based polling with webhooks where possible
• Configure dead-letter queues and alert on depth > 0
• Test in sandbox under realistic load; confirm headroom under 6,000 req / 5 min
• Remove old web service registrations once consumers are stable
• Confirm zero deprecation warnings remain in the admin centre
• Document the new integration inventory for the next person

FAQ

Was SOAP removed from Business Central entirely in version 29?

Not entirely. Version 29 (October 2026) removed SOAP endpoints exposed on standard, Microsoft-authored UI pages — the Feature Management key that let you re-enable them is now mandatory, so it can no longer be turned off. SOAP endpoints built on codeunits or your own per-tenant extension pages are not removed by version 29. However, SOAP as a whole has been deprecated since Business Central 2021 Wave 1 and will eventually be removed entirely, so treat every remaining SOAP integration as a migration candidate.

What’s the difference between page-based OData and the REST API v2.0?

Page-based OData exposes a UI page object directly as a REST endpoint, which means UI logic (field visibility, FlowFields, page triggers) runs on every call — slow and fragile. The REST API v2.0 (/api/v2.0/...) is a purpose-built, versioned API tier with JSON responses, decoupled from the UI and designed for machine-to-machine communication. Custom API pages/queries written in AL are the replacement for page-based OData when you need custom data or logic.

What’s the recommended replacement for SOAP web services?

Microsoft recommends the built-in REST API web services (API v2.0) as the primary replacement, with OData v4 as a secondary option. For custom data or business processes, write API pages or API queries in AL. If you have a genuine reason to keep a page-based SOAP integration beyond version 29, the supported path is to replicate the Microsoft page as a per-tenant extension object and publish that extension page as a SOAP endpoint.

How do I find which integrations are affected?

Two places: (1) Settings → Web Services — every entry with Type = Page and a SOAP/OData URL is at risk; (2) the RT0053 telemetry signal in Application Insights, which shows every actual call hitting deprecated endpoints (as opposed to what’s merely published). Run the audit across all environments, including sandboxes.

What about Unbound Actions that can only be called via OData?

This is a real gap. Unbound Actions currently have no equivalent in the REST API v2.0 surface. Options: re-architect the action as a bound action (tied to a record, which REST supports), expose it through a custom API page/codeunit, or keep a thin OData shim on a custom page until Microsoft closes the gap. Flag these early in the audit — don’t discover them at cutover.

Do I need extra licenses to migrate to the REST API?

No. The REST API v2.0 and custom API pages/queries are included in your existing Business Central subscription. Additional licensing (Copilot credits, Power Platform) only applies if you’re separately building AI agents on top — that’s a different project.

When should I start if I still use SOAP?

Now. Version 29 is already out, so SOAP calls to Microsoft pages stop working as soon as your environment is updated to it — and Microsoft’s update period for a major version lasts five months from release, plus a one-month grace period. A proper audit plus migration of a handful of custom integrations realistically takes 1–2 months. If you run revenue processes (EDI order intake, bank feeds, shipment data) over SOAP on Microsoft pages, that’s your immediate priority. Page-based OData on Microsoft pages follows in version 30 (2027 release wave 1).

Still running integrations on SOAP or page-based OData? Book a scoping call → We’ll audit your environment, map every affected endpoint, and migrate you to the REST API v2.0 — before your version 29 update, not after. Or explore our custom development and integration services for the AL API pages that replace your legacy endpoints.