Apr 08

OData Deprecation in Business Central: What Your Integration Architecture Needs Right Now

The Clock Is Ticking on Your OData Endpoints If you have integrations connecting to Business Central through OData web service endpoints, you need to start planning your migration today. Not next quarter. Not when v30 drops. Today. Microsoft has been signalling this move for years, but the concrete timeline is now clear. Version 30 (2027 Wave 1) will remove the ability to expose Microsoft-authored pages as OData endpoints entirely. Version 26 already shows warnings. Version 28 continues tightening. And SOAP endpoints? Those are being fully removed in version 29 (2026 Wave 2). This is not a minor API version bump. This is a fundamental shift in how Business Central expects external systems to communicate with it. And if you are running a multi-system architecture where BC is one node in a larger integration mesh, the impact goes well beyond swapping one URL for another. Why Microsoft Is Doing This (And Why They Are Right) The core argument is straightforward: UI pages were never designed to be APIs. They were designed for humans to interact with. When you expose a page like the Customer List as an OData endpoint, you are tying your integration to a contract that Microsoft never intended to be stable. Every time Microsoft updates the layout, adds a field, or restructures a page for user experience reasons, your integration is at risk of breaking. This has been a constant headache for years. Partners discover after an update that a field moved, a column disappeared from the default view, or a filter stopped working the way it used to. API Pages solve this by creating a purpose-built, versioned surface for programmatic access. They have explicit contracts. They are designed for throughput and filtering. They support proper versioning so that when Microsoft releases API v2.1, your v2.0 integrations keep working. From a design perspective, this separation between the human interface and the machine interface is exactly right. It just means a lot of work for everyone who took shortcuts. What Is Actually Changing: The Technical Timeline Let me break down the timeline with specifics: Version 26 (2025 Wave 1, already live): Warnings appear when you try to expose Microsoft UI pages as OData endpoints. SOAP endpoints for Microsoft pages are blocked by default. The telemetry signal RT0053 becomes available, which is your best friend for auditing what your tenants are actually calling. Version 28 (2026 Wave 1, current): Standard API surface continues to expand. New APIs arrive for sustainability, ESG reporting, and additional supply chain scenarios. OData deprecation warnings persist and become more prominent. Version 29 (2026 Wave 2): SOAP endpoints are fully removed. If anything still depends on SOAP, it will simply stop working. Version 30 (2027 Wave 1): OData support for Microsoft-authored pages is removed. Custom pages exposed as OData will still work, but Microsoft strongly recommends moving everything to API pages or API queries. There is also an important detail that often gets missed in discussions. Unbound Actions, which can currently only be called through OData (not the REST API), do not yet have a replacement in the REST API surface. This is a gap that Microsoft needs to address, and it is worth tracking closely. If your integrations use unbound actions on codeunits exposed through OData, you are in a particularly tricky spot. The Real Problem: It Is Not Just About Swapping URLs Most of the migration guides I have seen online focus on the mechanical steps. Find your OData endpoints, create equivalent API pages, update your connection strings. That is the easy part. The hard part is dealing with the knock-on effects: Different data shapes. API pages do not mirror UI pages. They expose a flatter, more predictable data structure. If your integration logic assumes the nested structure of an OData response from a page like the Sales Order, you will need to rethink your data mapping layer. Different filtering behaviour. API pages use OData v4 query parameters, but the available filter fields, supported operators, and response pagination differ from what you get when querying a UI page. Integrations that rely on complex filters need careful testing. Different authentication patterns. If you are moving from legacy OData with basic auth (still surprisingly common in on-prem to cloud migration scenarios), you will need proper OAuth 2.0 flows with Azure AD. This is a good thing, but it is also a significant change for some middleware setups. Rate limiting. The BC API enforces per-user limits of 6,000 OData requests per 5-minute sliding window, a maximum of 5 concurrent requests, and 100 simultaneous connections. If your integration was chatty against OData pages, you may need to rethink your request patterns. Missing API coverage. Not every entity that you can currently access through OData UI pages has a corresponding standard API. You will need to identify gaps early and plan to either build custom API pages or use API Queries for read-only scenarios. A Practical Migration Approach Here is how I would approach this in a real project, based on patterns I have used across integration implementations: Step 1: Audit Everything Before you write a single line of code, you need a complete inventory. Use the RT0053 telemetry signal in Application Insights to discover every external call hitting deprecated endpoints. This is not optional. You will be surprised at what you find. Middleware that someone set up three years ago and forgot about. A Power Automate flow that a functional consultant created. A reporting tool pulling data nightly. Run this across all your environments. Production, sandboxes, everything. If you do not have Application Insights configured, that is your actual first step. Step 2: Classify by Complexity Not all integrations are equal. Sort your discovered endpoints into three buckets: Simple swaps: The entity has a direct standard API equivalent. Customers, Vendors, Items, Sales Orders, Purchase Orders. These are relatively straightforward. Change the endpoint URL, adjust the data mapping, test, deploy. Custom API pages needed: The entity does not have a standard API, or your integration needs a specific data shape that the standard API does not provide. You will need to create custom API pages in a Per-Tenant Extension or AppSource app. Architectural rework required: The integration relies on patterns that do not translate directly. Unbound actions, complex multi-step operations that depend on page triggers, or scenarios where the integration was essentially screen-scraping a page through OData. Step 3: Design Your Custom API Pages Properly When you build custom API pages, do not just copy the structure of the UI page. Design the API for its actual consumers. Think about what fields the calling system actually needs. Think about the filters that will be applied. Think about whether an API Query would be better suited for read-only reporting scenarios. API Queries deserve special attention. They let you join data across tables and return exactly the shape your consumer needs, without the overhead of a full page object. For reporting integrations, data warehouse feeds, and analytics pipelines, API Queries are often the better choice. Step 4: Version From Day One One of the biggest advantages of API pages is versioning. Use it. Do not publish a custom API without a version number. When your requirements change (and they will), publish a new version alongside the old one. Give your consumers time to migrate. This is the discipline that UI pages as OData never gave you. The Unbound Actions Gap I want to call this out specifically because it is the one area where the migration story is incomplete. If you have integrations that call BC codeunits as unbound actions through OData, there is currently no REST API equivalent. Microsoft has not announced when or how this will be addressed. The practical options right now are: Wait and watch for Microsoft to fill this gap. This is risky if you are on a tight migration timeline. Wrap the logic in a custom API page with a bound action. This works for many scenarios but changes the calling pattern. Move the orchestration logic outside of BC entirely. Use Azure Functions or Logic Apps to coordinate the multi-step operations, calling individual API endpoints as needed. I lean toward option 3 for complex scenarios. It gives you more control, better error handling, and cleaner separation of concerns. But it is more work upfront. What This Means for Your Architecture If you are building new integrations today, the path is clear: use API pages, use the standard API v2.0, and design for the modern REST surface from the start. If you are maintaining existing integrations, start your audit immediately. Budget time for the migration in your 2026 and early 2027 planning cycles. Do not wait for the deadline. And if you are building middleware or integration platforms that connect BC to other systems, think about abstraction layers. Build your BC connector against the API surface with a clean mapping layer that isolates your business logic from the specifics of how BC exposes data. This way, when Microsoft eventually evolves the API further, your impact surface is contained. The deprecation of OData is not a crisis. It is Microsoft doing the right thing by separating the user experience from the machine interface. But it does require real effort, and the teams that start planning now will have a much smoother transition than those who wait until the warnings turn into errors.

Microsoft is removing OData support for first-party pages in Business Central v30 (2027 Wave 1), and SOAP endpoints disappear even sooner in v29. If your integrations rely on exposing UI pages as web services, the migration clock is already running. This post walks through the full deprecation timeline, explains why swapping URLs is only 20% of the work, covers the unbound actions gap that nobody is talking about, and lays out a practical four-step migration approach for teams managing multi-system architectures. Start planning now, not when the warnings turn into errors.

Feb 24

The Long Road Toward a New Beginning

The Long Road Toward a New Beginning

There comes a point in every career where experience quietly changes shape. It stops being about learning new tools or delivering the next project and starts becoming something more personal. How you want to work. What you want to build. The kind of impact you want to leave behind. After fifteen years across multiple companies, …

Continue reading

Nov 20

Directions EMEA 2025 – Reflections, Insights, and the Dawn of a New Era for Business Central

For me, Directions EMEA always begins long before the first sessions start. It begins with the long-haul travel, the endless airport corridors, the confused time zones, and the inevitable jetlag that becomes a yearly companion. Since 2018, this has been my routine, exhausting, unpredictable, and yet somehow comforting in its familiarity. But every year, without …

Continue reading

Jun 21

From BC TechDays to the Heart of Business Central

What a whirlwind! Just seven days ago, I was on stage in Antwerp, and before the applause faded, I was already airborne to Denmark to huddle with the Business Central product group. (Stay tuned – those behind-the-scenes conversations deserve their post.) Today, though, I want to capture the magic of BC TechDays 2025 – the …

Continue reading

May 15

Directions Asia 2025: People, Power, Progress

As I flew back from Directions Asia 2025 this morning, I felt inspired to jot down my thoughts during the quieter moments of the flight. My wife and daughter quickly drifted off, likely exhausted from our exciting nights filled with vibrant parties and adventures in the lively city of Bangkok. It was a joy to …

Continue reading

Apr 24

Directions ASIA 2025 – Join Us in Bangkok!

I’m excited to announce that I will speak at Directions ASIA 2025 alongside Steve Gichure. This year, the event expands to three full days of learning, networking, and innovation, and we can’t wait to be a part of it. 💙 This event is also extra special because my wife, Shanika Ranathunga, plans to join me! …

Continue reading

Apr 23

Simplify Per-Tenant Extension Management in Dynamics 365 Business Central

The new functionality available in the admin centre has simplified the management of per-tenant extensions (PTE). Administrators can now oversee PTES directly from the Business Central Admin Centre and its API, similar to how AppSource apps are managed. ​ This enhancement reduces administrative overhead by removing the need for individual access to each environment, facilitating …

Continue reading

Apr 23

Search, navigate and use app symbols as context for GitHub Copilot

Working with large AL codebases and multiple dependencies can often make locating specific objects or references difficult. With the latest updates, we can expect significant improvements! Search Downloaded Symbols with Ctrl+T It is now possible to search AL objects from downloaded symbol packages directly in Visual Studio Code using the ‘Open Symbol by Name’ (Ctrl+T) …

Continue reading

Apr 09

Implicit Conversion Between Record and RecordRef

With recent updates to the AL language extension (v15), Microsoft has introduced support for implicit conversion between Record and RecordRef instances, making it easier to work with both types in the code.

This feature removes some of the verbosity previously required when switching between Record and RecordRef variables, allowing developers to write cleaner, more concise AL code.

Mar 17

Ternary operator ?: in AL

AL language now supports ternary (conditional) operator. The ternary operator? : known from other programming languages, streamlines conditional operations in code, enhances readability and reduces verbosity. The following examples show how the code  GetBooleanText() can be rewritten using the ternary operator to be less verbose and more succint. Without the ternary operator: With the ternary operator …

Continue reading