DigitalSolveWorks

Reference

NAV to Business Central integration pattern reference

A working map from legacy Dynamics NAV integration patterns to their Business Central SaaS equivalents — what each legacy pattern looks like in practice, the actual mechanism that stops it from surviving the move to SaaS, and what replacing it involves.

This is a reference, not a diagnosis. The correct target pattern for any specific integration is confirmed during assessment, not assumed from a table — an environment's actual constraints (data volume, existing middleware, downstream system capability) routinely change which option is the right one.

The eight patterns below cover the great majority of what shows up in a legacy NAV integration surface: ways external systems read and write NAV data, ways NAV called out to other systems, ways background work got done without a user at a keyboard, and ways documents and reports left the system. Four of them — direct SQL access, hardcoded credentials, SOAP services, and NAS — share a single underlying shift, shown below before getting into each pattern individually.

The shared shift underneath most of the patterns below: direct, ungated access into an on-premises process is replaced by an identity-gated API boundary. Not every pattern below routes through this exact path — control add-ins, NAS, and reporting have their own mechanisms — but this is the throughline for four of the eight.

1. Direct SQL table access

Legacy pattern
An external system — a WMS, a BI tool, a middleware layer — connects straight to the NAV SQL Server database, usually via a linked server, ODBC connection, or a service account with a SQL login, and reads or writes NAV tables directly.
Target BC SaaS pattern
BC API pages or standard OData v4 endpoints, called over HTTPS and authenticated with OAuth 2.0, consumed by the external system in place of a table query.

This is the pattern that survives the least gracefully, because the change isn't a permissions tightening — it's the removal of an entire access layer. On Business Central SaaS there is no customer-accessible database at all: no linked server target, no ODBC connection string, no SQL login to provision, because the database itself sits inside a Microsoft-managed multi-tenant service that was never designed to expose a query surface to a customer's own tooling. Treating this as "we'll just need a firewall exception" or "we'll ask for a read-only login" is the single most common estimation mistake in this list — there is nothing to ask for.

The replacement is a BC API page (custom-built to the shape the external system needs) or, where the entity already has one, a standard API v2.0 OData v4 endpoint — both authenticated via an Entra ID app registration using the OAuth 2.0 client-credentials flow. Migrating this pattern means re-modeling the integration around request/response calls instead of table scans: if the external system relied on a database trigger to detect changes, that has to move to either polling the API on an interval or subscribing to webhook notifications for near-real-time change detection. The external system's own code changes, not just its connection string — this is usually the largest single line item in a re-architecture scope.

2. .NET interop assemblies

Legacy pattern
A custom or third-party .NET assembly, loaded in-process via a DotNet variable and called synchronously from C/AL — used for anything from custom cryptography and file parsing to calling a vendor SDK directly.
Target BC SaaS pattern
AL HttpClient calling out to an Azure Function (or equivalent middleware) that hosts the equivalent logic as a REST endpoint.

It's worth stating the mechanism precisely here, because it's easy to get slightly wrong in a way that undermines an estimate. AL does still have a DotNet data type — but it is available only to extensions built for an on-premises target. An extension compiled for the cloud target cannot use it at all, because a multi-tenant sandboxed service has no mechanism to load a customer-supplied assembly into its own process. So this is not an artifact of the C/AL-to-AL conversion itself, which on-premises can carry the pattern forward more or less intact; it is a genuine SaaS boundary, and it is the target that decides it.

The fix is to relocate the logic, not just re-point the call. Whatever the assembly did — a translation routine, a signing operation, a call into a vendor SDK — moves out of the AL codebase entirely and into an Azure Function (or similar middleware) that exposes it as a REST endpoint. The AL side then makes an outbound AL HttpClient call to that endpoint. It's worth being precise about direction here: AL HttpClient is how Business Central calls out to something else — it is the direct replacement for an outbound .NET interop call. It is not a mechanism for an external system to reach into Business Central; that's the API-page/OData pattern in section 1, a different direction entirely, and conflating the two is a common and visible mistake.

3. File-drop and polling jobs

Legacy pattern
A scheduled job — run via NAS, Windows Task Scheduler, or a Job Queue entry — that scans a network file share on an interval, picking up files an external system dropped there (or dropping files for another system to pick up).
Target BC SaaS pattern
An event-driven trigger on cloud storage (an Azure Blob container or a SharePoint library) that pushes data into BC via its API the moment a file arrives, replacing the poll entirely.

The mechanism here is simpler than it looks: Business Central SaaS is a managed multi-tenant service that does not run inside a customer's own network, so a UNC path to an on-premises file share was never something it could reach in the first place — this isn't a permission that got revoked, it's a network boundary that never existed on the SaaS side. Any integration built around "drop a file, wait for it to be picked up" needs an intermediate location both sides can actually reach.

The practical replacement is to land files in Azure Blob Storage (or a SharePoint document library, via BC's external file storage capability where the use case is document attachments rather than data interchange) and trigger an Azure Function or Logic App the moment a new blob appears. That trigger then calls the relevant BC API to create or update the record the file represented — the scheduled scan is replaced by an event, not by a faster scan. Where the data volume or cadence doesn't justify a full event-driven pipeline, a Job Queue entry can still poll — but it polls an API endpoint or a blob container listing, never a local or network file system, because AL on SaaS has no path to one.

4. Hardcoded service credentials

Legacy pattern
A dedicated NAV integration user record with a stored, often long-lived password, used by an external system or middleware layer to authenticate against NAV's database or web services.
Target BC SaaS pattern
The OAuth 2.0 client-credentials flow, via an Entra ID app registration, issuing short-lived tokens instead of a shared static password.

This pattern is inseparable from the ones above it: it disappears partly because its usual destination (a SQL login, or a NAV/Windows-authenticated session) no longer exists, and partly because Business Central SaaS authenticates everything — human and machine — through Microsoft Entra ID. There's no local user table row to point a static password at any more: machine-to-machine access is issued and validated by Entra ID, not by a credential stored inside the tenant's own data.

Migrating this means registering an Entra ID application, granting it the appropriate Business Central API application permissions, and issuing it a client secret or (preferably) a certificate. The external system's authentication step changes from "connect with a username and password" to "request a token from Entra ID, then present that token on every call" — a real code change on the consuming side, not just a credentials swap, and one with its own new obligation: secret or certificate rotation needs an owner and a schedule, since that risk didn't exist under the old model.

5. SOAP web services

Legacy pattern
NAV pages or codeunits published as SOAP web services — historically the first integration surface most NAV environments built, often the oldest code in the integration inventory.
Target BC SaaS pattern
BC API pages, or a standard API v2.0 OData v4 endpoint where one already covers the same entity.

This is the one pattern in this list that doesn't simply stop working — published objects can still be exposed over SOAP on Business Central. The reason to move off it isn't removal, it's that Microsoft's investment has gone entirely into the OData v4/API-page surface for years: SOAP endpoints don't get delta/change-tracking query options, don't participate in the standard versioned API schema, and can't be wired into webhook-driven notification the way an API page can. A SOAP integration is a dead end for new capability even on days when it's technically still answering requests — which makes it easy to under-scope, since nothing is visibly broken yet.

Migrating it starts with checking whether the entity the SOAP service exposed already has a standard API v2.0 equivalent — many common ones do, which turns this into a client-side rewrite rather than a new server-side build. Where it doesn't, a custom API page shaped to match the old SOAP response keeps the client-side change smaller. Either way, the consuming client's authentication and payload handling both change: OAuth 2.0 in place of whatever the SOAP client used, and JSON in place of a SOAP envelope.

6. NAV Application Server (NAS)

Legacy pattern
A dedicated, non-interactive NAS instance hosting scheduled or continuous background processing — batch jobs, EDI runs, recurring integration tasks — with no client UI attached.
Target BC SaaS pattern
Job Queue entries for AL-side scheduled processing that fits within the managed service's execution limits; Azure-side scheduling (a Function on a timer, a Logic App recurrence) for anything that doesn't.

The mechanism is the same one behind several patterns above: a NAS instance is a customer-managed server process, and Business Central SaaS has no customer-managed server processes of any kind — the entire service tier is operated by Microsoft, with no mechanism to stand up a background process of your own and point it at a SaaS tenant. Whatever ran on NAS has to run somewhere else now.

For most straightforward recurring AL logic, a Job Queue entry is the direct successor — it schedules codeunit execution inside the managed service itself, no separate process to install or monitor. The catch is that Job Queue entries run within the same session constraints as any other AL execution: execution-time limits, no persistent listening socket, no long-running background thread. Anything that genuinely needs to run continuously, hold open a connection, or do substantial work outside AL's own limits has to move out to Azure-side scheduling — a Function on a timer trigger, or a Logic App recurrence — calling into Business Central through its API rather than running inside it. Cataloguing which NAS jobs are "simple scheduled AL" versus "actually needs to live outside AL" is most of the migration effort here.

7. Windows client control add-ins

Legacy pattern
A .NET control add-in built for the Windows RTC client — direct hardware access (barcode scanners, local printers), or custom rich UI controls the standard client couldn't provide.
Target BC SaaS pattern
A JavaScript control add-in in the web client, which remains a fully supported extensibility surface — plus Universal Print, or a small bridging service, for hardware the browser sandbox can't reach directly.

It's worth stating plainly what does and doesn't survive here, because this is a point that's easy to get backwards: control add-ins as a concept are not unsupported on SaaS. JavaScript control add-ins are fully supported in the Business Central web client today. What's gone is specifically the .NET-based Windows client control add-in — a mechanism tied to a Windows client process that Business Central SaaS users don't run at all, since SaaS is a browser-based web client exclusively. The extensibility model didn't disappear; it moved to JavaScript.

The real constraint that shows up during migration isn't "add-ins are unsupported," it's the browser sandbox: a JavaScript control add-in executing in a browser tab cannot open a raw socket to a printer or scanner sitting on the local network the way a .NET add-in running on a Windows desktop could. For document-style printing, Universal Print is Microsoft's first-party cloud printing answer and is usually the first thing to evaluate — Business Central integrates with it natively, and if the hardware is Universal Print-compatible, this becomes a configuration task rather than an architecture problem. The gap is that Universal Print is oriented toward driver-driven document printers, and label printers driven by raw ZPL/EPL command streams frequently fall outside what it handles cleanly. Where that's the case, the realistic options are a cloud print API from the label hardware vendor, or a small locally-installed bridging service that receives a print job from BC over HTTPS and forwards it to the printer on the local network — a genuine design decision, not a drop-in replacement, and one worth resolving early since it tends to have the longest lead time in an otherwise straightforward migration.

8. Reporting integrations

Legacy pattern
Custom report layouts rendered via an on-premises SQL Server Reporting Services instance tied to NAV, and/or a third-party BI or reporting tool querying NAV's SQL tables and views directly for cross-system analytics.
Target BC SaaS pattern
Word or RDLC report layouts rendered by Business Central's own service — no separate report server involved — plus API pages, OData v4, or the Power BI connector for external analytics in place of direct SQL extraction.

This pattern actually splits into two different failures with two different fixes, and it's worth keeping them separate. The report-layout half survives better than expected: AL reports still support both RDLC and Word layout types, and that hasn't changed — what disappears is the customer-managed SSRS server that used to render them. On SaaS, report rendering is handled entirely inside the managed service itself, so existing RDLC or Word layouts generally port with a review pass (branding, fonts, data item structure) rather than a rebuild — the technology survives, the server it used to depend on doesn't.

The BI/analytics half fails for the same reason as direct SQL access in section 1, because that's exactly what it is: a reporting tool querying NAV tables directly hits the same "no customer-accessible database layer at all" wall, just from the analytics side rather than the transactional side. The replacement path is the same one, too — API pages, standard OData v4 endpoints, or (where the target is specifically Power BI) its native Business Central connector, in place of a scheduled SQL extraction job. Migrating this means re-pointing whatever pulled data for reporting purposes at an API or OData feed instead of a connection string, and re-checking refresh cadence against whatever polling or webhook pattern replaces the old direct query.

This reference will be extended as new legacy patterns come up in assessment work. For a specific environment, the Assessment offer classifies each integration point against these patterns and estimates the remediation effort; the Re-architecture Capacity offer delivers the migration itself as fixed-fee work into your repository. Questions on a pattern not covered here can go to the contact page.