Hire Microsoft Dynamics 365 experts
Hire Microsoft Dynamics NAV developers
In short
MS Dynamics Guys provides Dynamics NAV developers who maintain the C/AL code in your NAV database and prepare its move to Microsoft Dynamics 365 Business Central. C/AL is the programming language of Dynamics NAV; Business Central extensions use its successor, AL. Your lead sets priorities. The developer fixes code on your version, commits every change to your repository and lists each customization, add-on and integration. Your team decides what to convert to AL, replace or retire.
When a NAV developer from MS Dynamics Guys fits
A NAV developer suits a company that keeps Dynamics NAV running for now, or is still deciding how to leave it. The developer reads and changes C/AL. Your people decide what the business still needs from each change.
Team situations that suit a NAV developer
- Fixes and small changes queue up, and nobody on your side can open the code in C/SIDE.
- The partner or employee who wrote your customizations has left, and nobody knows why parts of the code exist.
- An upgrade is under discussion, but nobody has listed what was changed, added or connected over the years.
- NAV must keep running for a while, and every change should be recorded in a form the upgrade can use later.
- Your upgrade partner needs a C/AL reader on your side while it converts the code.
When a different role or service fits better
- Nobody on your side can decide which customizations still matter. A developer can list and explain them, but only your process owners can rule on them.
- The open questions are about setup or posting rules in NAV, not code. A functional consultant from your team or your partner answers them. The developer can show where the code reads that setup, but does not decide it.
- You want one provider for the whole upgrade, or a fresh start without the old code. The table below shows what fits instead.
- The gap is moving records and proving the totals, not code. A data migration engineer owns that work.
- The gap is setup, posting rules and test scripts in Business Central. That is work for a Business Central consultant.
- Interfaces to other systems must be rebuilt for Business Central and watched after go-live. An integration engineer owns that work.
- Your system is Dynamics AX, a different product with its own language. It needs a Dynamics AX developer.
- Your system is Dynamics GP, which reaches Business Central by its own migration path. A Dynamics GP migration expert fits that work.
NAV maintenance or a Business Central migration team?
NAV support can mean maintaining C/AL under your lead or planning a move to Business Central. A developer adds capacity to your maintenance backlog. An upgrade needs its own scope and acceptance. Find your situation and the first deliverable below.
| Your situation | What to buy | First deliverable |
|---|---|---|
| NAV stays in use for now, and fixes queue up | A NAV developer who works under your lead | A tested C/AL fix with a release note, ready for your administrator to import |
| An upgrade is under discussion, but nobody has listed what changed | A NAV developer who builds the inventory and the path note | An inventory of customizations, add-ons and integrations, with a proposed treatment for each |
| The upgrade is approved, and a partner will convert the code | Your partner, plus a NAV developer who reads and fixes the C/AL | Answers to the partner's questions, and a log of C/AL fixes that the partner converts again |
| The upgrade is approved, and you want one provider for it | A NAV to Business Central upgrade from MS Dynamics Guys | A pilot conversion of a representative set of objects |
| The code already runs as AL extensions | A Business Central developer who writes AL | A tested change to one extension |
| You prefer a fresh start to converting old code | A Business Central implementation, with functional and data migration roles as needed | A data scope: which records move, with no code conversion |
A NAV developer is not an upgrade team. The developer knows the old code. The conversion, the data upgrade and the cutover also need AL skills, Business Central setup and one owner for the plan.
Microsoft offers one more route to a fresh start. Its reimplementation tool moves only essential data from Business Central 14, such as master data, open sales and purchase orders, opening balances and setup. C/AL customizations and their data stay behind. The tool is a preview feature, and Microsoft says preview features are not meant for production use. Even this route starts with an upgrade from NAV to version 14.
Work a NAV developer can own
The developer owns the code work and the written record of what exists. Your people own the decisions, the license and the imports into production.
| Work | What the developer delivers | What your team provides or decides |
|---|---|---|
| C/AL fixes and small changes | Each change built and tested in a copy of your database, exported as text to your repository and described in a release note | A reviewer for the exported text, named in the agreement; a process owner who confirms the fix; and an administrator who imports it into production |
| Object inventory | Every modified standard object and every custom object, found by comparing your database with an unmodified one of the same version, cumulative update and country version | A restored copy of production, and the installation media or a clean database for your exact version |
| Add-ons and extensions | Each add-on from an independent software vendor (ISV), with its publisher, version and object range. Each V1 extension, the first extension model, built in C/SIDE. | Contact with each publisher, who says whether a Business Central version of the add-on exists |
| Platform dependencies | .NET add-ins, MenuSuite entries, and code that relies on codeunit 1, which Business Central replaced with system codeunits | Decisions on features that depend on local hardware or files, such as label printers |
| Integrations | Each web service that other systems call over SOAP or OData, two standard web service protocols. Each system that reads NAV tables directly in SQL Server, each file exchange and each job queue entry that runs an interface. | The owner of each connected system |
| Data and treatments | A flag on every custom table and added field that stores data, and a proposal for each item: convert to AL, replace with a standard feature or a Microsoft Marketplace app, or retire | Your process owners rule on each proposal and say which data still matters |
| Path note and freeze proposal | The supported path from your NAV version to the target, and a proposed date after which C/AL changes stop | Your sponsor chooses the path. Your lead and your upgrade partner agree the freeze date. |
You supply process owners who can say what each customization is for, the NAV license for the development copy, and every import into production.
Platform facts that shape NAV work
Six facts from Microsoft's documentation decide how a NAV developer works and what the inventory must record:
- Data in customized tables. Data from tables with code customizations reaches Business Central online only when AL extensions handle those customizations, installed both on-premises and online. A field that nobody converts leaves its data behind. So the inventory flags every field and table that stores data, and each decision is made on purpose.
- The upgrade path. NAV reaches Business Central through upgrades on-premises. NAV 2015 to 2018 go through Business Central 14 and version 25, and older NAV versions need extra steps first. The code must become AL on the way, and Business Central online comes last, through a cloud migration. The developer's path note gives the exact steps for your version.
- Version 14 is a step. Microsoft lets new customers use version 14 only as an upgrade path, not in production. Microsoft's Txt2Al tool, which turns C/AL objects exported as text into AL files, ships only with version 14 and is not available from version 21. V1 extensions must become V2 extensions, written in AL, while the system is still on version 14 or earlier.
- Web services. OData V3 was removed in version 18. From version 29, a Microsoft page can no longer be a SOAP endpoint, and Microsoft has announced the same removal for OData endpoints on Microsoft pages in version 30. An interface that calls a standard NAV page should get a new design: Business Central's standard application programming interface (API) v2.0, a custom API page or a copy of the page in an extension.
- Access to the database. In Microsoft's NAV 2018 documentation, a developer gets C/SIDE access to a database through the
db_ownerrole in SQL Server. That role allows any configuration and maintenance work on the database, including deleting it. So the developer holds the role on a copy, and production stays with your administrator. - Text and .fob files. Text exports let a reviewer compare each version of an object in your repository. For imports, the NAV 2018 documentation notes two differences. A text import needs a developer license and overwrites objects with the same ID. A .fob file, the NAV object file format, imports with an end-user license too and shows conflicts in the Import Worksheet first. So each release reaches your administrator as a .fob file built from the reviewed text.
Our NAV to Business Central upgrade service covers the whole route, from the version path to cutover.
Rebuilding interfaces on Business Central APIs is integration work: see Business Central integration.
How we assess a NAV developer before you meet them
Each candidate works on C/AL that MS Dynamics Guys wrote for the exercise, not on client code. The exercise starts with a change to a posting codeunit that fills a new field on posted invoice lines. A reviewer checks the written answers against the skills below, and you receive the result before your interview.
| Skill | Exercise and review | Evidence you receive |
|---|---|---|
| Reading C/AL | Explain what the posting change does, which tables it touches and what breaks if the new field is missing from one of them | A written explanation, with the reviewer's notes |
| Upgrade paths | Write a path note for the NAV version the candidate has worked on most, from that version to the current Business Central release | The path note, checked against Microsoft's published upgrade paths |
| Conversion design | Say where the posting change could live after conversion: a subscriber to an existing event, another design, or an extensibility request to Microsoft, filed in its BCApps repository on GitHub, when no suitable event exists | A short design note |
| Data before a cloud migration | Explain what happens to the data in the new field if nobody converts the field before a move to Business Central online | A written answer |
| Integrations and add-ins | Propose replacements for a SOAP web service on a standard page and for a .NET add-in, given what Business Central online allows | A replacement note for each |
| Fixes during conversion | A defect turns up while the code is being converted, and NAV is still live. Explain where to fix it and how the fix reaches the converted code. | A written answer, compared with Microsoft's guidance |
Only candidates who pass are introduced.
The buyer scorecard for Microsoft Dynamics 365 specialists has a rubric that works for any role. Pair it with the posting-codeunit change above to compare NAV developers from other suppliers.
Example first work package
Keep NAV running, plan the move or hand over the upgrade
How long NAV stays in use, and who should own the move, decide the option. The middle column shows who directs the daily work in each one.
| Option | Who directs the daily work | Choose it when |
|---|---|---|
| One NAV developer in your team: staff augmentation | Your lead, who sets the order of NAV fixes and inventory work | NAV stays in use for a while, or the inventory needs someone who answers to your team |
| A NAV to Business Central upgrade project | Our project lead, within the agreed scope | You want one provider to answer for the conversion, the data upgrade and the cutover |
Allocation (full-time or part-time), overlap hours, minimum term, notice and replacement are agreed in writing per engagement. Staff augmentation versus project delivery compares the models side by side.
When the developer leaves, the inventory, change log and release notes are already in your repository, and a named person on your team gets a walkthrough of them.
Starting on a copy of your NAV database
These steps add NAV specifics to the hiring hub's path from role brief to shortlist. They cover your exact version, a restored copy of your database and, if an upgrade is planned, the freeze rules agreed with your partner.
Your role brief
Name your NAV version, cumulative update and country version. List the add-ons, the integrations, the work waiting and any date by which a Business Central decision is due.
Fit review
We check whether the gap is C/AL maintenance, an inventory, conversion work or a data move, and name the role or service for each part.
Assessed candidates
You receive each candidate's written answers on the posting-codeunit exercise, with the reviewer's notes.
Your interview
Bring one customization from your own database. Ask the candidate to explain it and to say what would happen to it in an upgrade. You decide who joins.
Written agreement
It names who directs the work, who reviews each C/AL change and who approves imports into production. If nobody on your side reads C/AL, the agreement names who does, such as your upgrade partner. It also sets the freeze rules if an upgrade is planned. It covers intellectual property, personal data in the database copy, overlap hours, notice and replacement.
Access to a database copy
Your administrator restores a copy of production and gives the developer a named login, with the
db_ownerrole on that copy only. The repository account is named too.First acceptance
A small fix, or the first part of the inventory, reviewed against criteria that your lead wrote.
The onboarding checklist for external specialists lists the accounts, contacts and rules to prepare.
What a NAV inventory should record: a demonstration
An inventory is the record that stays with you after the developer leaves. MS Dynamics Guys wrote the five entries below as an original demonstration of the standard we expect. The objects and the business are invented, and nothing comes from client code.
This page shows no client stories or reviews.
How we assess specialists describes our review process and the limits of any screening task.
| Inventory entry | What it does | Stores data? | Proposed treatment | Who decides |
|---|---|---|---|---|
| A field added to the Customer table | Holds a credit insurance limit that posting code checks | Yes | Convert: a table extension for the field and an event subscriber for the check | The credit controller |
| A change inside a standard posting codeunit | Writes each posted invoice to a custom log table | Yes, in the log table | Convert if anyone still reads the log; otherwise archive the table and retire the code | The finance lead |
| A .NET add-in | Prints shipping labels on a local printer | No | Replace: look for a Microsoft Marketplace app or an external printing service first, because .NET interop is not available online | The warehouse lead |
| A SOAP web service on the standard Item Card page | Sends item data to a web shop | No | Replace with API v2.0 or a custom API page, because Microsoft pages can no longer be SOAP endpoints from version 29 | The web shop owner |
| A MenuSuite entry for a custom report | Lets users find the report | No | Retire the entry, and set the report's search properties during conversion | No business decision needed |
In a real inventory, each entry also records the object type and ID, the version tag and the person who confirmed what the change is for.
Can a NAV developer from MS Dynamics Guys keep NAV running while our partner plans the upgrade?
Yes, if three things are agreed in writing first. Without them, the old code and the converted code drift apart.
- Copy access. The developer works in a copy of production, not in the live database. Your upgrade partner starts from the same baseline: the object export taken when the inventory was made.
- A shared change log. Every C/AL change after that baseline is logged with its object, its reason and its release date. The partner reads the log and converts each changed object again.
- An agreed freeze. Microsoft's customization migration guide says to stop C/AL development before the final cutover and to do all new work in AL extensions. Your lead and the partner set that date.
Until the freeze, fixes start in C/AL. Microsoft recommends this order for teams that still maintain C/AL during a conversion: fix the error in the C/AL objects, then convert again. The two code bases stay similar, and later changes are easier to carry forward.
The developer does not change the partner's converted code. Design questions go to the partner. Questions about what a customization is for go to your process owners.
Questions about hiring Dynamics NAV developers
Does C/AL experience mean the developer can write AL?
Not by itself. AL replaced C/AL after Business Central 14, and the way code changes the product changed with it. A C/AL developer edits the standard objects directly. An AL extension adds to them through events and extension objects, and Business Central online runs extensions only.
So we assess AL separately. A candidate who should also convert code completes the Business Central developer exercise as well.
Which NAV versions does MS Dynamics Guys work on?
Name your version, cumulative update and country version in the role brief. Before anyone is introduced, we confirm in writing whether we can staff a developer for that exact version. Each written result names the NAV versions the candidate has worked on, so your interview can test the one you run. The version also sets the route: NAV 2013 needs more upgrade steps to reach Business Central than NAV 2018 does.
Is our NAV version still supported by Microsoft?
Check the dates before you plan. Microsoft's extended support has ended for NAV 2016 and every earlier version. It ended in April 2026 for NAV 2016, January 2025 for NAV 2015, January 2023 for NAV 2013 and 2013 R2, and January 2020 for NAV 2009 Service Pack 1 and R2. For NAV 2017 it ends in January 2027, and for NAV 2018 in January 2028.
A developer can maintain your own code after those dates. That does not extend Microsoft's support for the product. See NAV lifecycle dates and Microsoft sources when planning maintenance and migration.
What happens to C/AL fixes made during the conversion?
Each fix is made in C/AL first and logged, and your partner converts the changed object again. Two limits apply. A fix must not remove or rename fields, because Microsoft warns that breaking schema changes stop the converted extension from synchronizing with the database. After the freeze date, fixes go into the AL extensions only, made by whoever owns them.
Our old partner left no documentation. Can the developer still find what was changed?
Yes, given one thing: an unmodified database of the same version, cumulative update and country version to compare against. The comparison shows every changed object, even where nobody updated the version tags. What a change was for is a separate question. The developer reads the code and proposes an answer, and your process owners confirm it. For add-ons, ask each publisher whether a Business Central version exists before anyone plans to convert its code.
How are cost and hours agreed for a NAV maintenance role?
The rate basis is agreed in writing per engagement, and this page quotes no figures. The total depends on the allocation, the overlap with your working hours and how long NAV stays in use. If fixes arrive in bursts, agree in the role brief how urgent requests reach the developer and how much time is reserved for them. Staff augmentation versus project delivery explains when paying for time fits better than paying for a result.
Discuss the NAV estate
Share your NAV version, the add-ons and integrations you know about, the work waiting and any date for a Business Central decision. Our reply says whether you need NAV maintenance, an inventory or a migration team, before anyone is introduced.
Product documentation referenced on this page
- Supported upgrade paths to Business Central on-premises Microsoft Learn, checked October 4, 2026
- Migrate Dynamics NAV to Business Central online Microsoft Learn, checked October 4, 2026
- Customization migration guide: Dynamics NAV to Business Central online Microsoft Learn, checked October 4, 2026
- Business Central 14 reimplementation tool for cloud migration (preview) Microsoft Learn, checked October 4, 2026
- Upgrade considerations Microsoft Learn, checked October 4, 2026
- Transitioning from codeunit 1 to system codeunits Microsoft Learn, checked October 4, 2026
- Converting extensions V1 to V2 Microsoft Learn, checked October 4, 2026
- The Txt2Al conversion tool Microsoft Learn, checked October 4, 2026
- Code conversion from C/AL to AL Microsoft Learn, checked October 4, 2026
- Deprecated features in the client, server and database Microsoft Learn, checked October 4, 2026
- Development Environment (C/SIDE), Dynamics NAV 2018 Microsoft Learn, checked October 4, 2026
- How to: Import Objects, Dynamics NAV 2018 Microsoft Learn, checked October 4, 2026
- Database-level roles (SQL Server) Microsoft Learn, checked October 4, 2026
- Create an extensibility request Microsoft Learn, checked October 4, 2026
- Migrate on-premises data to Business Central online Microsoft Learn, checked October 2, 2026
- Calling .NET from AL (on-premises only) Microsoft Learn, checked October 2, 2026
- API page type Microsoft Learn, checked October 2, 2026
- Extension types and scope Microsoft Learn, checked October 2, 2026
- Programming in AL Microsoft Learn, checked October 2, 2026
- Testing the application overview Microsoft Learn, checked October 2, 2026
- Dynamics NAV 2018 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2017 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2016 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2015 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2013 R2 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2013 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2009 R2 lifecycle Microsoft Learn, checked October 4, 2026
- Dynamics NAV 2009 lifecycle Microsoft Learn, checked October 4, 2026