Dynamics NAV + on-prem AI
AI for Dynamics NAV 2009-2018, before or instead of a Business Central migration
Short answer
Dynamics NAV 2009 through 2018 still runs manufacturing and distribution operations at a large number of companies with no immediate plan to move to Business Central. A private LLM grounded on NAV's SQL Server database through its own naming conventions can answer inventory, order, and production questions directly, without touching a single C/AL object or requiring the migration first.
- ERP
- Microsoft Dynamics NAV 2009, Dynamics NAV 2013-2018, Navision (legacy)
- Industries
- Manufacturing, Distribution
- Written for
- IT Director
Dynamics NAV in its classic C/AL form (2009 through 2018, spanning the classic client, the Role Tailored Client, and the early NAV web client years) is still the operational system of record at a large number of manufacturers and distributors. Most of them are on NAV because a Business Central migration has been deferred, not because C/AL is strategic, and every year that deferral continues, the gap between what the ERP can do natively and what a modern AI-literate workforce expects gets wider.
The honest starting point for an IT director evaluating this is that NAV's underlying data model is genuinely solid. Tables like Item Ledger Entry, G/L Entry, Sales Header and Sales Line, and Production Order are well-normalized and have not changed much in their core shape since the Navision days, which is precisely what makes them a good foundation for an AI layer. The obstacle has never been the data; it has been that answering a question out of it requires either C/AL knowledge or a request to whoever built the last custom report.
What works is connecting directly to the SQL Server database NAV runs on, reading through the company-prefixed table structure NAV uses under the covers, and grounding a model on that with a semantic layer that translates NAV's naming conventions into plain business language. For versions 2013 and later, NAV's web services (SOAP and OData v3) offer an additional, more API-friendly path for some data; for earlier classic-client installations, a direct SQL connection is usually the only realistic option, and it works fine for read-only grounding.
The AI layer runs entirely off the NAV database server, on separate infrastructure with its own compute, and never writes back to a NAV table directly. That constraint matters twice over: it protects a database that many IT teams already treat as fragile after years of customization, and it means the project can start delivering value without waiting on, or being blocked by, the eventual Business Central decision.
What usually gets in the way
The problems we hear most from it director teams running Microsoft Dynamics NAV 2009.
Item, order, and production status requires NAV or a saved report
Answering what shipped, what is in stock, or where a production order stands means opening NAV or waiting on a report someone built years ago, rather than asking a direct question.
Multi-company table prefixes complicate anything ad hoc
NAV's database structure prefixes every table with the company name, which is manageable for a report writer but a real obstacle for anyone trying to build quick, ad hoc queries across companies.
C/AL knowledge is scarce and aging out
The people who understand NAV's custom C/AL objects, codeunits, and table relationships are often the same people who set the system up a decade or more ago, and that knowledge rarely gets written down.
Reporting tooling predates modern expectations
RDLC and Classic reports serve their purpose but were not built for self-service, natural-language questions, leaving business users dependent on IT for anything not already built.
Microsoft's AI investment goes to Business Central, not legacy NAV
Copilot and generative AI features are being built into Business Central; NAV 2009-2018 customers get no native path to the same capability without migrating first.
Where AI earns its place in Microsoft Dynamics NAV 2009
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Natural-language item and inventory queries
A planner or buyer asks about on-hand quantity, item ledger history, or reorder status in plain English, answered from live Item Ledger Entry and Value Entry data.
Touches: Item Ledger Entry, Value Entry, Item table
Outcome: Cuts routine inventory questions from a report request to a direct answer, cited against the source ledger entries.
General ledger and dimension inquiry
A controller asks about account balances, journal detail, or spend by dimension without waiting on a custom report or a filtered NAV view.
Touches: G/L Entry, Dimension Set Entry, Chart of Accounts
Outcome: Reduces ad hoc reporting requests to the ERP team while keeping every figure traceable to a posted journal entry.
Sales order and shipment status lookup
Customer service and planning staff ask what has shipped against an order, or what remains open, without a saved-report lookup.
Touches: Sales Header, Sales Line, Sales Shipment Header/Line
Outcome: Faster order-status answers for staff who are not comfortable navigating NAV directly.
Production order and capacity exception flags
An agent compares production order progress against routing and capacity data to flag orders trending late before the ship date is at risk.
Touches: Production Order, Prod. Order Routing Line, Capacity Ledger Entry
Outcome: Surfaces at-risk production orders earlier than a manual, end-of-week review would.
AP document intake and PO matching
OCR and classify vendor invoices, then propose a match against open Purchase Line data for a clerk to confirm before posting.
Touches: Purch. Inv. Header/Line, Purchase Line
Outcome: Cuts manual keying and matching effort on routine invoices while leaving the actual posting to a person.
C/AL customization documentation assistant
Point a code-aware model at exported C/AL object source to generate plain-English descriptions of what each custom object does, ahead of any modernization or migration decision.
Touches: Exported C/AL objects (tables, codeunits, forms/pages)
Outcome: Builds a documentation baseline in weeks, reducing dependence on the one or two people who remember why a codeunit branches the way it does.
Pre-migration data and customization profiling
An agent profiles which tables, fields, and custom objects are actually in active use, giving a future Business Central migration decision real usage data instead of guesswork.
Touches: Cross-reference of object usage, custom field and table inventory
Outcome: Turns migration scoping into an evidence-based exercise rather than a manual inventory project.
Reference architecture
A read-only layer on NAV's SQL Server database, grounded through a semantic mapping of its company-prefixed table structure, running on separate infrastructure that never writes back to a NAV object.
- 1
NAV connectivity
Direct SQL Server read replica or scoped read-only login against the NAV database, or NAV web services (SOAP/OData v3) where 2013-and-later versions have them enabled.
- 2
Semantic layer
A mapping from NAV's company-prefixed tables and C/AL field names to plain business terms, built with whoever on staff still understands the customizations.
- 3
Model serving
Open-weight models served on a separate host from the NAV database server, sized to query volume rather than to NAV's own licensing or performance constraints.
- 4
Retrieval and agents
Text-to-SQL for structured questions across item, order, and production data; scheduled exception agents for production and capacity; document RAG for AP intake and C/AL documentation.
- 5
Governance and audit
Every generated query and answer logged with the source table and record identifiers, so IT can trace an AI answer back to the NAV rows it came from.
Integration notes for your ERP team
- For NAV 2013 and later, evaluate whether SOAP or OData v3 web services are already enabled before defaulting to a direct SQL connection; either path can work, but web services can simplify authentication and access scoping.
- Account for the company-name table prefix explicitly in the semantic layer; a multi-company NAV install needs the mapping built once per relevant company, not assumed generic.
- Build the semantic layer with whoever on staff still knows the C/AL customizations; this is the highest-leverage step and the one most legacy NAV projects underinvest in.
- Keep the database connection strictly read-only at the login level; any future write-back should go through NAV's own web services or a person entering data directly, never a raw table write.
- For classic-client (pre-2013) installations without modern web services, plan on a SQL Server read replica or linked server as the only realistic connectivity path.
- Export C/AL object source to a flat file store for the documentation use case, rather than granting the model any access to the NAV object designer itself.
- If a Business Central migration is on the roadmap, capture object and table usage data from this project as a natural input to that scoping exercise, without treating the AI project as contingent on it.
Deployment options
Air-gapped on-prem
Manufacturers and distributors with no appetite for ERP data leaving the building, or with customers who require it.
Model and read replica run on the same network segment as the NAV database, with no outbound path required for inference.
Private or sovereign cloud
Companies open to cloud economics but not to a shared public AI API touching operational ERP data.
Model serving in a dedicated-tenant cloud environment, connecting to on-prem NAV over a site-to-site VPN or a similarly controlled connection.
Hybrid
IT teams wanting to prove one use case on modest hardware before committing to a wider rollout or a migration decision.
A scoped pilot on a small GPU or CPU instance, same architecture, extended or migrated once the use case is proven.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
SOX / financial controls
Read-only access to G/L Entry for reporting use cases; any AI-proposed adjustment routes through NAV's own journal entry workflow, never a direct write.
GDPR / data protection
For NAV customers with EU operations, the read replica and any document store stay within the same data residency boundary the company already applies to NAV itself.
Change control
The AI project runs entirely outside NAV's object library, so it does not touch existing change management scope for the ERP, and does not require a C/AL object migration to deliver value.
Data retention
Read replica retention and access logging matched to the company's existing NAV backup and retention policy, with no new offsite copy created without sign-off.
Where Netray fits
ERPray
ERPray's connector architecture fits a NAV read replica the same way it fits any relational ERP: point it at the semantic layer, keep it read-only, and it answers questions with the underlying query shown.
Custom build
C/AL customization documentation and pre-migration usage profiling are typically custom builds, since they work directly with exported object source rather than a packaged connector.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -Table and field mapping for the target use case (inventory, GL, or production)
- -Confirmed connectivity path (SQL replica vs. web services)
- -Read-only access and security review with IT
- -Pilot scope and success criteria
Phase 2 . 6-8 weeks
Pilot
- -Working replica and semantic layer for the pilot data domain
- -Model serving stood up on separate infrastructure from the NAV database server
- -5-10 real user questions answered end to end with cited sources
- -Pilot review with IT director and business sponsor
Phase 3 . 6-10 weeks
Production
- -Hardened replica refresh cadence tuned to the use case
- -Role-based access aligned to existing NAV security
- -Audit logging of queries and answers
- -Runbook for IT to operate and maintain the connector
Phase 4 . ongoing
Scale
- -Additional data domains (production, AP) added to the semantic layer
- -C/AL documentation extended to more custom objects
- -Quarterly review of query patterns to prioritize the next use case
Questions to ask any vendor, including us
A short list that separates real Microsoft Dynamics NAV 2009 AI work from a chatbot demo.
- Does your approach require any change to NAV C/AL objects, or is it strictly read-only against the database?
- How do you handle the company-name table prefix in a multi-company NAV environment?
- Who builds the semantic mapping from NAV's table and field names to business terms, and how much staff time does that take?
- Where does the model run relative to our NAV database server, and does any data leave our network?
- What happens to this project if we later decide to migrate to Business Central?
- Can you show a real example of the SQL your system generated against Item Ledger Entry or a production order?
- How do you handle NAV versions without modern web services, such as pre-2013 classic-client installs?
- What is your rollback plan if the read replica falls behind during a period close?
Frequently asked questions
Can I add AI to Dynamics NAV without migrating to Business Central?
Yes. NAV's data lives in an ordinary SQL Server database, reachable read-only through a replica or, for 2013-and-later versions, through NAV's own web services. An AI layer can query and summarize that data without touching NAV's C/AL objects or requiring a Business Central migration.
Does this change or write to my NAV data?
Not by default. The standard architecture is strictly read-only, with any proposed write reviewed by a person before it is entered into NAV through normal channels. Write-back is possible later but is a deliberate, separately scoped decision.
How do you handle NAV's company-prefixed table names?
The semantic layer explicitly accounts for the company-name prefix NAV applies to every table, mapped once per relevant company as part of discovery, so multi-company installations are handled correctly rather than assumed generic.
Will this put extra load on our NAV database server?
Model inference and vector storage run on a separate host, not on the NAV database server itself. The only load on NAV is the replication or query feed, tuned to stay well within normal database activity.
Is this relevant if we are already planning to move to Business Central?
Often more relevant, not less. A read-only AI project can also profile actual table and object usage, giving a future Business Central migration scoping exercise real usage data, while you still get value from NAV in the meantime.
What about our custom C/AL objects nobody has documented?
A code-aware model can read exported C/AL object source and generate plain-English descriptions of what each one does, useful as a documentation baseline for onboarding staff or scoping a future migration, without executing or modifying the code.
Does this work for NAV 2009 classic-client installations, not just later versions?
Yes. Earlier classic-client installations without modern web services typically connect through a direct SQL Server read replica instead, which works just as well for grounding an AI layer, since the underlying table structure is largely consistent across NAV 2009 through 2018.
Related guides
AI for Dynamics GP and NAV, Before the Business Central Decision
Dynamics GP mainstream support is ending and NAV is long retired from active development. Add a private LLM over GP or NAV data now, on-prem, without a forced Business Central move.
AX 2012 + private AIAI for Dynamics AX 2012, Without the Forced Migration
Dynamics AX 2012 R3 left mainstream support in 2021. Add a private LLM over AX data now, use it to de-risk a future migration, without a forced move to D365.
Business Central Manufacturing + AIAI for Business Central manufacturing operations, beyond Copilot
AI for Business Central manufacturing beyond Copilot: grounded answers on production orders, routings, and capacity via APIs v2.0, on-prem capable.
ERP migration + on-prem AIAI-assisted data migration for ERP implementations
AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
D365 F&SCM + private AIAI for Dynamics 365 Finance and Supply Chain beyond Copilot
AI for D365 Finance and Supply Chain beyond Microsoft Copilot: private LLM grounded on data entities and OData, on-prem-capable via Local Business Data.
Plan it with numbers
Legacy ERP AI Modernization Assessment
Score your legacy SyteLine, LN, or Baan environment to find out whether AI can modernize it in place or whether platform upgrade work needs to come first.
Free ToolERP Upgrade vs Replace Assessment
Answer 10 questions about your current ERP's support status, fit, customization burden, and costs to see whether upgrading or replacing is the stronger path.
Free ToolERP Migration Risk Assessment
Answer 10 questions about your data, team, testing, and budget to get a migration risk score and a prioritized list of mitigations before your project starts.
GuideLegacy ERP Modernization with AI Agents
Modernize legacy ERP systems with AI. Gradual transformation from BPCS, MAPICS, BAAN, and other legacy systems to modern Infor cloud ERP.
GuideERP Cloud Migration Strategy Guide
Plan your ERP cloud migration with a proven strategy covering assessment, architecture selection, data migration, and go-live. Includes AWS, Azure, and GCP options.
GuideNatural Language ERP Query Interface
Query your ERP using natural language. Transform plain English questions into SQL/API calls with LLM-powered interfaces that democratize ERP data access.
Talk it through with an engineer who knows Microsoft Dynamics NAV 2009
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.