NAV 2017 support ends January 11, 2027: the upgrade path to Business Central

Dynamics NAV 2017 follows Microsoft's Fixed Lifecycle Policy, and its extended support ends on January 11, 2027 (Microsoft's lifecycle page puts the cutoff at January 12, 6:59 AM Pacific). After that: no security updates and no support from Microsoft. NAV 2018, the last NAV release, follows a year later, in January 2028.

If you have clients on NAV 2017, here is what the road to Business Central looks like, and where the work actually is.

The path goes through version 14

There is no direct jump from NAV 2017 (version 10) to current Business Central. Microsoft's documented upgrade paths go through Business Central 2019 release wave 1 (version 14), the last version that still runs C/AL:

1. Upgrade NAV 2017 to version 14. Your customized C/AL objects come along; it is the last stop where they work as they are.
2. Turn the customizations into AL extensions, or replace them with standard features. Data that lives in fields you added to base tables has to end up in the extension's tables during the upgrade.
3. Upgrade to the target version. On-premises, the path now goes through 2024 release wave 2 (version 25) on the way to current releases. For Business Central online, you move from a supported on-premises version with the cloud migration tool, and only data in standard or extension tables comes along: data in tables changed by code customizations doesn't.

The exact steps shift with each release, so check Microsoft's current upgrade paths and compatibility matrix for your target version before planning.

Where the work is

The mechanical steps (the database upgrades, Txt2Al turning C/AL into AL syntax) are documented and fairly predictable. The time goes into three places.

The customizations. Every one gets the same question: does Business Central do this out of the box now? If yes, use the standard. If not, rebuild it as an extension around events instead of modified base code. I covered that sorting in an earlier post on NAV customizations.

The reports and documents. Custom reports convert with the rest of the C/AL code, and their RDLC layouts can often be reused. But a modified copy of a standard report (the invoice, almost always) is better rebuilt as a report extension on today's standard report, so it keeps getting Microsoft's fixes. One thing to know on current versions: since 2026 release wave 1, report layouts have a status, and an imported layout starts as a draft that won't print until it's approved.

The integrations. NAV 2017 integrations tend to be file drops, SOAP web services, job queues on the NAV Application Server, and sometimes direct SQL. Online, direct SQL is gone, and the rest is better rebuilt on the APIs. For anything that runs outside Business Central, Azure Functions are a good home.

Functional and development work split cleanly

These projects need two kinds of expertise. The functional side reviews the processes (receiving, production, warehouse, billing), runs the fit-gap workshops against standard Business Central, and trains the users. The development side builds what the fit-gap finds missing: extensions, reports and documents, integrations, data migration, and the tests.

If you're a functional consultant or a partner short on AL capacity, the development side is what I take on: estimating the gaps, building them as extensions that survive updates, and testing them with the client's real documents.

Before January 11

For clients who will still be on NAV 2017 for a few months:

• keep the NAV server off the internet; remote access goes through a VPN;
• test the backups by actually restoring one;
• restrict access to the people who need it;
• freeze Windows and SQL Server changes unless NAV is tested first.

The deadline doesn't mean every client has to be migrated by January 11. It means every client should have a plan by then.

Clients still on NAV 2017? Let's talk.