1. Executive summary
This report was prepared for a hypothetical scenario: Example Manufacturing Co., an illustrative, fictitious mid-market discrete manufacturer running Microsoft Dynamics NAV 2017 on-premises, invented solely to demonstrate this deliverable's format. The scope was the client's integration surface — the custom and semi-custom connections between NAV and the outside systems it exchanges data with — assessed for compatibility with a future move to Business Central SaaS.
The headline finding, illustrative for this hypothetical environment: of the ten integration points identified, two already use a SaaS-compatible pattern and need no work, five require re-architecture of varying difficulty, and one — a Windows client control add-in used for label printing — has no direct SaaS equivalent and needs a design decision, not just a migration task, before it can be scoped at all.
The blocking risk in this hypothetical scenario is that same label-printing integration. It is currently treated as a minor, "figure it out later" item in informal planning conversations, but it is architecturally the hardest problem in the inventory and the one most likely to blow up a fixed-price migration bid if it surfaces late. The recommended commercial path is to resolve the design question for that one integration point before quoting the migration project as a whole — everything else in the inventory can be estimated with reasonable confidence today.
Read in full, this report gives a VAR principal enough to have a specific, defensible conversation with a client about scope, sequencing, and price — without needing to re-derive any of the technical analysis first.
2. Environment summary
Hypothetical scope, for illustration only — not a real environment.
- Source system
- Dynamics NAV 2017, on-premises, C/AL codebase (illustrative)
- Migration target
- Business Central, SaaS (illustrative)
- Integration points identified
- 10 (illustrative count, for this walkthrough only)
- Integration types in scope
- Direct SQL access, .NET interop assemblies, a Windows client control add-in, file-drop/polling jobs, a SOAP web service, existing OData v4 API endpoints, and document/report sharing
- Assessment turnaround
- 4 business days (illustrative, within the standard 3–5 day range)
3. Integration inventory and SaaS-compatibility classification
Every integration point identified in this hypothetical environment, classified against Business Central SaaS constraints — no direct SQL access, no on-tenant .NET assemblies, no local file system, no Windows client control add-ins.
| Integration point | Current pattern | SaaS compatibility | Target BC pattern | Effort |
|---|---|---|---|---|
| WMS order sync | Direct SQL read/write against Sales Header/Line tables | Incompatible | BC API page / OData v4 endpoint consumed by the WMS | Medium–High |
| EDI 850/810 translation | .NET interop assembly called from C/AL | Incompatible | AL HttpClient call to an Azure Function hosting the translation logic | Medium |
| Label printing | Windows client .NET control add-in | Incompatible, no direct equivalent | Requires a redesign decision (browser-capable printing service or third-party label API) before a target pattern can even be named | High |
| 3PL inventory feed | Nightly CSV drop, picked up by a scheduled polling job | Partially compatible | Event-driven trigger (Logic App or Azure Function on file arrival) replacing the poll | Medium |
| Legacy reporting tool access | Hardcoded service account credentials stored in an integration user record | Incompatible | OAuth 2.0 client-credentials flow via an Entra app registration | Low |
| Invoice PDF hand-off to shipping portal | Posted invoice PDFs written to a shared network folder, polled by the portal | Incompatible, no shared file system on SaaS | External File Storage (Azure Blob) plus a BC API page exposing the document reference | Medium |
| Legacy CRM order lookup | SOAP web service exposing sales order data | Compatible with modification | Replace with the equivalent standard BC API page (OData v4); SOAP remains a legacy surface Microsoft steers new integrations away from | Low–Medium |
| Payment gateway authorization | Synchronous .NET interop call to the gateway's SDK | Incompatible | AL HttpClient calling the gateway's REST API directly | Medium |
| E-commerce item availability feed | Standard OData v4 API page | Already compatible | No change — already SaaS-ready | None |
| Power BI reporting connection | Standard OData feed against published queries | Already compatible | No change — already SaaS-ready | None |
Illustrative inventory for the hypothetical scenario described above. A real assessment lists exactly what exists in the environment being assessed — nothing here is a template of expected findings.
WMS order sync: why direct SQL access has no partial fix
In this hypothetical scenario, the warehouse management system reads open sales orders and writes shipment confirmations directly against NAV's SQL tables using a linked-server connection. On Business Central SaaS there is no customer-accessible database layer at all — not a locked-down one, an absent one — so this is not a tuning or permissions problem, it is a full protocol change. The replacement is a set of BC API pages (or, where the shape fits, standard OData v4 endpoints) that the WMS calls instead of querying tables, authenticated via OAuth 2.0 client credentials rather than a SQL login. The design work is mostly on the WMS side: order and shipment payloads need to be re-modeled around a request/response API instead of a table scan, and if the WMS currently relies on database triggers to detect changes, that behavior needs to move to either polling the API on an interval or subscribing to BC's webhook notifications.
EDI translation: interop breaks even though the direction is outbound
The EDI integration in this scenario calls a .NET assembly from C/AL to translate NAV documents into 850/810 formats before handing them to a trading-partner network. It is tempting to assume this migrates cleanly because the call is already "NAV calling out," but the mechanism matters: a .NET interop assembly runs in-process alongside the NAV service tier, and Business Central SaaS does not allow customer-supplied .NET code to run in-process at all. The fact that the call is outbound is what makes the fix straightforward rather than what makes it unnecessary — the translation logic itself needs to move out of NAV entirely and into an Azure Function (or equivalent middleware), and the AL code's job becomes making an outbound AL HttpClient call to that Function's REST endpoint instead of invoking the assembly directly. The translation logic is preserved; only where it runs changes.
Label printing: the one item that isn't a migration task
The label-printing integration uses a Windows client .NET control add-in to talk directly to network-attached label printers from the NAV Windows client. This specific pattern has no SaaS equivalent: .NET control add-ins are a Windows-client-only extensibility mechanism, and Business Central SaaS users work exclusively through the web client. JavaScript control add-ins do remain a fully supported extensibility surface in the web client, but they execute in a browser sandbox and cannot open a raw socket to a printer on the local network, so they do not rescue this pattern either.
Microsoft's first-party answer, Universal Print, is what to evaluate first — Business Central integrates with it natively, and if the label hardware is Universal Print-ready this stops being an architecture problem and becomes a configuration one. The catch 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, which is why this cannot be assumed away at estimation time.
This row is flagged separately from every other item in the inventory because it cannot be estimated as "effort to migrate an existing pattern." It requires a decision first — Universal Print if the hardware supports it, a cloud print API from the label hardware vendor, or a small on-premises middleware service that receives a print job from BC over HTTPS and forwards it to the printer on the local network — and only then does an effort estimate mean anything. In this hypothetical scenario, this is exactly the kind of item recommended for early, standalone scoping rather than folding into the general migration estimate.
Illustrative phasing for the hypothetical scenario. The label-printing design decision (Phase 4 delivery) is deliberately investigated starting in Phase 1, since it has no dependency on the other work and the longest lead time.
4. Remediation roadmap and sequencing
Sequencing in this hypothetical scenario is driven by two things: which integrations share a dependency (an OAuth-based authentication foundation is needed before several others can be built against it), and which item has the longest lead time before it can even be scoped (the label-printing redesign, which is why its design investigation starts immediately rather than waiting for Phase 4 execution).
| Phase | Integration points | Why this grouping | Effort band |
|---|---|---|---|
| Phase 1 — Foundation | Legacy reporting credentials, legacy CRM SOAP replacement | Establishes the OAuth 2.0 client-credentials pattern that later phases reuse; the SOAP replacement is low effort and de-risks the API-page approach early | Low |
| Phase 2 — Core data integrations | WMS order sync, EDI translation | Both depend on the Phase 1 authentication pattern and are the highest-value, most business-critical connections | Medium–High |
| Phase 3 — Files and documents | 3PL inventory feed, invoice PDF hand-off, payment gateway | Independent of each other; sequenced after core data integrations because none of them block go-live on their own | Medium |
| Phase 4 — Label printing | Label printing redesign | Design decision investigated from Phase 1 onward given its lead time; implementation effort is not fully estimable until that decision is made | High (provisional) |
Effort bands are illustrative for this hypothetical scenario, not a pricing commitment — a real assessment ties each band to the specific complexity found in the environment being assessed.
5. Risk register
| Risk | Severity | Mitigation |
|---|---|---|
| Label-printing redesign has no established target pattern and could stall the whole project if discovered late | High | Investigate and decide the printing approach in Phase 1, in parallel with unrelated work, rather than deferring it |
| EDI translation logic inside the .NET assembly is only lightly documented | Medium | Reverse-engineer behavior via representative test-case comparison before rewriting as an Azure Function |
| Running WMS sync against both the old SQL path and the new API in parallel during cutover risks data drift | Medium | Add a reconciliation job comparing both paths during a defined parallel-run window before decommissioning the SQL path |
| OAuth client-credential secrets introduce a rotation obligation that did not previously exist | Low | Use certificate credentials on the Entra app registration and document a rotation schedule |
| Shared network folder for invoice hand-off is a single point of failure with no SaaS equivalent | Medium | Move to Azure Blob-backed External File Storage ahead of the general migration, since it is a self-contained change |
Reminder: everything above is an illustrative template built on a hypothetical, fictitious environment (Example Manufacturing Co.). It is not a real client engagement, and none of the counts, effort bands, or findings should be read as a benchmark, an industry average, or a measured result. An actual assessment is built entirely from the specific environment being assessed, and its findings will not resemble this example.
About this template
This page exists to make the Assessment offer evaluable before anyone commits to it — the format, structure, and level of technical detail shown here is what a real, paid assessment looks like, applied to a real environment instead of a hypothetical one. For a real environment, reach out through the contact page to discuss scope; there is no live call involved, engagement starts by exchanging a description of the environment and, once an NDA is in place, whatever access or extracts are needed to produce the actual report.