Dynamics NAV 2017: End of Support 2027 and the Shop Integration

Extended support for Microsoft Dynamics NAV 2017 ends on 11 January 2027 (Microsoft Lifecycle). With it, the security updates at no additional cost that this phase has included so far come to an end. Anyone who has connected an online shop to NAV 2017 now faces two tasks at once: moving to Business Central and moving the shop interface. Migration plans tend to treat the second part as a side issue, yet day-to-day business depends on it: orders, stock, prices and customer data. This guide shows the paths to Business Central, why the old SOAP and OData pages do not carry over as an interface, and how to move to API v2.0, OAuth and webhooks while both systems run in parallel, without orders getting stuck. Our page on the Dynamics NAV integration describes which data typically flows.

What ends on 11 January 2027

Dynamics NAV 2017 follows Microsoft's Fixed Lifecycle Policy (Microsoft Lifecycle). The version was released in October 2016, mainstream support ended in January 2022 (Microsoft Lifecycle), and extended support ends on 11 January 2027 (Microsoft Lifecycle). Microsoft states all support dates in Pacific Time (Microsoft Lifecycle). For planning in Germany, 11 January 2027 is therefore the cut-off date.

The Fixed Lifecycle Policy provides a minimum of five years of mainstream support, during which Microsoft also ships non-security updates and accepts requests to change features (Microsoft Lifecycle). In extended support, where NAV 2017 has been since January 2022, there are security updates at no additional cost, but no new features and no design changes (Microsoft Lifecycle). On 11 January 2027 this phase ends as well. For the time after that, the policy only mentions security updates through an Extended Security Update program (Microsoft Lifecycle). For NAV 2017, the product page lists no such program.

Support dates of the NAV versions at a glance

All dates come from Microsoft's lifecycle pages and are given in Pacific Time (Microsoft Lifecycle). Internally, NAV 2017 carries version number 10 (Microsoft Learn). If you run NAV 2018, you have one more year. The last row is worth noting: Business Central 14, the first stop on the way from NAV to a current version, has itself been out of support since October 2025 (Microsoft Lifecycle). It only works as an intermediate step, not as a target.

Why the shop integration is the critical part

In Dynamics NAV, shop integrations usually run through web services. NAV supports OData web services in addition to the SOAP web services that have been available since Dynamics NAV 2009 (Microsoft Learn). What gets published are pages and codeunits: pages deliver items, stock or customers, codeunits encapsulate processes such as the order import. In NAV, codeunits cannot be accessed through OData (Microsoft Learn), which is why order imports in particular often depend on SOAP. Authentication uses a user name and password or a web service access key, unless the server is set to Windows authentication (Microsoft Learn).

Business Central does not take this technology over unchanged. There, SOAP is considered superseded by OData V4, and Microsoft recommends migrating integrations to OData V4 as soon as possible (Microsoft Learn). OData V3 has been removed since Business Central 2021 release wave 1 (Microsoft Learn). From version 29.0, that is with 2026 release wave 2, Microsoft pages can no longer be published as SOAP endpoints (Microsoft Learn). From version 30, which is due with 2027 release wave 1, the same applies to OData endpoints (Microsoft Learn). Microsoft pages are all pages from apps with the publisher Microsoft, including the Base Application. If you still need such pages as endpoints, Microsoft says you have to copy them into an extension of your own.

A UI page isn't an API, so changes to them can happen in a release without being considered a breaking change.

Microsoft Learn, Deprecated features in the platform

Then there is authentication. In Business Central online, integrations that sign in with a web service access key (Basic Auth) stopped working after 1 October 2022, and OAuth2 is the only authentication option there (Microsoft Learn). For Business Central on-premises, the access key remains an option for the time being. The interface version has moved on as well: the standard API v1.0 was dropped with version 28.0, the current one is API v2.0 (Microsoft Learn). A shop integration built today therefore relies on API v2.0 and OAuth, not on published UI pages. If you already run a middleware layer between shop and ERP, you only replace its ERP side; if your shop is connected directly to NAV, you rebuild the connection.

Old and new integration compared

The table shows why simply changing the address rarely suffices. Almost every row calls for a decision in the integration: new keys, a new sign-in, a new way of handling changes and error handling that can deal with the per-user limits. Business Central online processes at most 5 OData requests per user at the same time; further requests wait in a queue, and a request that has waited 8 minutes times out with status 503 (Microsoft Learn). Our article on connecting Business Central shows how batch requests and retry logic respond to this.

Which paths lead from NAV 2017 to Business Central

There is no direct jump from NAV 2017 to the cloud. If you are currently on a version of Dynamics NAV, you must first upgrade to Business Central on-premises and can only then switch to Business Central online (Microsoft Learn). Both paths to the cloud start with the upgrade to Business Central version 14 (Microsoft Learn). To reach the current version, Microsoft lists a chain of intermediate steps for NAV 2017:

1. Upgrade from NAV 2017 to Business Central Spring 2019, version 14. This converts the application from C/AL to AL (Microsoft Learn).
2. Upgrade from version 14 to Business Central 2024 release wave 2, version 25. A direct step from version 14 to the newer versions is no longer supported since version 26 (Microsoft Learn).
3. Upgrade from version 25 to the on-premises target version, currently version 29 from 2026 release wave 2 (Microsoft Learn).
4. If desired, the switch to Business Central online with the cloud migration tool, which is possible directly from version 25 (Microsoft Learn).

For the move to the cloud, Microsoft distinguishes two variants. Full migration carries over all data and customizations and requires converting C/AL customizations into AL extensions (Microsoft Learn). Reimplementation with the Business Central 14 reimplementation tool carries over only master data, balances, a subset of posted history and setup data, and in return does not require converting customizations (Microsoft Learn); Microsoft currently lists the tool as a preview.

If you stay on-premises, the lifecycle model changes. Business Central on-premises from 2019 release wave 2 onwards falls under the Modern Lifecycle Policy, and Microsoft only supports the software if the business keeps it current (Microsoft Learn). Version 29, for example, released in October 2026, is supported until April 2028 (Microsoft Lifecycle). Instead of one big upgrade every few years, regular updates are due, and each of them also affects the shop interface.

The new interface: API v2.0, OAuth and webhooks

Business Central provides standard APIs for integrations that can be called via REST from any programming language (Microsoft Learn). In API v2.0, records carry unique GUID keys and can be retrieved via the immutable SystemId (Microsoft Learn). This has consequences for the move: the shop has so far known items and customers by their NAV numbers, in future it also needs the SystemId, or the integration translates between the two. Standard APIs cannot be extended with additional fields. If you need fields that NAV delivered through a customized page, you copy the API into a custom API page and extend it there (Microsoft Learn). Our article on connecting Business Central to Shopware describes in detail what an integration with a Business Central system that is already running looks like.

For authentication, an application account rather than a personal user account is the better choice for a shop integration. Microsoft distinguishes between signing in on behalf of a user, which requires an interactively signed-in user, and service-to-service authentication of an application (Microsoft Learn). The application is registered in Microsoft Entra ID and receives access tokens without anyone sitting at a screen. Permissions are granted as narrowly as possible: the integration reads items, stock and prices and creates orders, nothing more.

Webhooks make a noticeable difference in daily operation. Instead of asking at intervals whether stock has changed, the integration subscribes to change notifications. Business Central does not send them immediately, but by default waits 30 seconds after the first change to a record (Microsoft Learn). If more than 1,000 records change during that time, a single collection notification arrives instead of individual ones (Microsoft Learn). A subscription expires after three days unless it is renewed before (Microsoft Learn). Our article on webhook architecture describes how to process such events cleanly in the shop. The integration creates a subscription for item changes roughly like this:

{
  "notificationUrl": "https://shop.example/bc-webhook",
  "resource": "/api/v2.0/companies({companyId})/items",
  "clientState": "{shared-secret}"
}

When a subscription is created and every time it is renewed, Business Central checks the target address: it has to return the validationToken it was sent in the response body with status 200 (Microsoft Learn). If Business Central cannot reach the subscriber, it retries delivery over the next 36 hours (Microsoft Learn). That only applies, however, if the subscriber responds with 408, 429 or an error in the 500 to 599 range; with any other code, the subscription is deleted (Microsoft Learn). A renewal job and periodic reconciliation as a fallback are therefore part of the integration.

Running in parallel: orders must not get stuck

For the shop, the most delicate moment of an ERP change is the cutover. A proven setup has the shop write orders not directly into the ERP but into a queue from which the integration picks them up. If the ERP stands still for a few hours, orders collect there instead of being lost. Each order carries the shop's order number as the external document number, so that a duplicate import stands out if an order arrives a second time after the cutover.

1. Inventory: Which web services does NAV 2017 publish, which of them does the shop use, in which direction, how often and with which account?
2. Mapping: For every field of the old interface it is clear where it comes from in Business Central: standard API, custom API page or calculation in the integration.
3. New integration against a sandbox: The interface is built against a Business Central sandbox and tested there with test orders.
4. Dry run: Microsoft recommends at least one full dry run of the migration in a sandbox before the cutover (Microsoft Learn); the shop integration runs along.
5. Shadow operation: The new integration reads stock and prices from Business Central but does not write anything yet. A comparison with NAV reveals deviations before customers see them.
6. Cutover: Pause order transfer, complete the last orders in NAV, migrate data, switch the integration, release the queue.
7. Follow-up: Reconcile orders, stock and payment status between shop and Business Central and monitor the interface.

That integrations belong in the migration plan is also stated in Microsoft's own roadmap: for the period after the migration, Microsoft explicitly lists reconnecting integrations, alongside enabling users and monitoring the environment (Microsoft Learn). In the project plan, the shop integration should therefore be a workstream of its own with its own test, not an item on the acceptance list of the ERP project. This applies all the more to real-time inventory sync across several channels, because there every delay shows up as overselling.

Inventory: what the old integration does today

Many surprises during the move come from tasks the old integration quietly took care of. It has often been extended over the years without anyone keeping a list of its tasks. An inventory before the first draft therefore saves time. It should answer these questions:

• Which pages and codeunits are published as web services in NAV, and which of them does the shop actually call?
• How does the shop sign in: with user name and password, with an access key or via a Windows account?
• Which custom fields does the interface transfer, such as additional item details, delivery terms or customer groups?
• How are customers created: does the shop create new customers in NAV, or does it assign orders to existing customers?
• Where do customer-specific prices and tiers come from, and how often are they synchronized?
• Who reports shipping status and tracking numbers back to the shop, and how?
• What happens on an error: are there retries, logs and a notification?
• Which other sources write orders into the ERP, such as orders by email or PDF that run through AI order entry?

The answers produce a mapping table with old source, new target, conversion and owner. It is the basis for development and later for acceptance. For B2B shops with customer groups, contract prices and approvals, it typically becomes considerably longer than for pure consumer shops; our page on B2B e-commerce shows which requirements are typically added there.

Timeline up to the end of support

Little time remains until 11 January 2027, especially since December is taken up by year-end closing and stocktaking in many businesses. A complete move to Business Central including a new shop integration often can no longer be finished in that time. What matters is an order of steps that reduces the risk first:

• Right away: Take inventory of the interface and decide on the target path, online or on-premises.
• Before the cut-off date: Shield the NAV server and the published web services. The web services should only be reachable for the integration, not openly on the internet, and should run encrypted over SSL, as Microsoft recommends for sign-in with password or access key (Microsoft Learn).
• In parallel: Build the new integration against a sandbox so that it is ready as soon as the ERP upgrade reaches the target version.
• After the cut-off date: Document continued operation of NAV 2017 as a temporary exception, with a fixed date for the cutover.

If you have other dates to keep an eye on at the same time, you will find them in the 2027 deadline calendar for online shops. And if your shop runs on Shopware 6.5, the end of security updates for Shopware 6.5 brings a second deadline shortly after the NAV cut-off date. Both changes can then sensibly be arranged in one joint plan so that shop and ERP are not rebuilt in the same week.

Typical pitfalls when moving the interface

• Subscriptions expire: A webhook subscription that is not renewed ends after three days (Microsoft Learn), and stock levels then silently stop updating. A monitoring job checks the expiry date in the expirationDateTime field.
• Throttling under load: With status 429, the integration needs a retry with a cool-off period (Microsoft Learn). Without it, updates get lost precisely at peak times.
• Custom fields are missing: What a customized NAV page delivered is not part of any standard API. This often only shows up in testing, when a field in the shop stays empty.
• Filters behave differently: Even NAV did not support an OR operator across different fields in OData filters (Microsoft Learn). Queries of the old integration are therefore rewritten for the API instead of being carried over unchanged.
• Two major updates per year: In Business Central online, new major versions arrive in April and October (Microsoft Learn). The integration should be tested before every update in a preview sandbox, which Microsoft provides about one month before the update (Microsoft Learn).
• Monitoring is missing: An interface that fails silently at night is noticed the next morning through customer enquiries. Monitoring the queue, errors and subscription status is part of the move, much like shop monitoring for availability and load time.

How we support moving the shop integration

We connect online shops with Dynamics NAV and Business Central, online and on-premises alike, and work on both sides of the interface. The ERP change itself is usually handled by a Microsoft partner; we focus on the part that day-to-day business in the shop depends on and coordinate it with the ERP project.

If it is still open which path suits your company, we clarify it in a consultation: starting point, target system, timeline and the question of what can realistically be achieved by 11 January 2027. Our page on integrations gives an overview of further ERP and marketplace connections.