Dynamics NAV 2017: Supportende 2027 und die Shop-Anbindung

Am 11. Januar 2027 endet der erweiterte Support für Microsoft Dynamics NAV 2017 (Microsoft Lifecycle). Mit ihm enden die kostenlosen Sicherheitsupdates, die diese Phase bisher umfasst. Wer einen Onlineshop an NAV 2017 angebunden hat, steht damit vor zwei Aufgaben zugleich: dem Wechsel auf Business Central und dem Umzug der Shop-Schnittstelle. Der zweite Teil gilt in Migrationsplänen gern als Nebensache, dabei hängt an ihm das Tagesgeschäft mit Bestellungen, Beständen, Preisen und Kundendaten. Dieser Leitfaden zeigt die Wege zu Business Central, warum die alten SOAP- und OData-Seiten als Schnittstelle nicht mitkommen und wie der Umzug auf API v2.0, OAuth und Webhooks im Parallelbetrieb gelingt, ohne dass Bestellungen liegen bleiben. Welche Daten dabei typischerweise fließen, beschreibt unsere Seite zur Dynamics-NAV-Anbindung.

Was am 11. Januar 2027 endet

Dynamics NAV 2017 unterliegt der Fixed Lifecycle Policy von Microsoft (Microsoft Lifecycle). Die Version erschien im Oktober 2016, der Mainstream-Support endete im Januar 2022 (Microsoft Lifecycle), und der erweiterte Support endet am 11. Januar 2027 (Microsoft Lifecycle). Microsoft gibt alle Supportdaten in Pazifikzeit an (Microsoft Lifecycle). Für die Planung in Deutschland zählt damit der 11. Januar 2027 als Stichtag.

Die Fixed Lifecycle Policy sieht mindestens fünf Jahre Mainstream-Support vor, in denen Microsoft auch Updates ohne Sicherheitsbezug liefert und Änderungswünsche an Funktionen annimmt (Microsoft Lifecycle). Im erweiterten Support, in dem sich NAV 2017 seit Januar 2022 befindet, gibt es Sicherheitsupdates ohne zusätzliche Kosten, aber keine neuen Funktionen und keine Designänderungen mehr (Microsoft Lifecycle). Mit dem 11. Januar 2027 endet auch diese Phase. Für die Zeit danach nennt die Richtlinie Sicherheitsupdates nur noch über ein Extended-Security-Update-Programm (Microsoft Lifecycle). Für NAV 2017 nennt die Produktseite kein solches Programm.

Supportdaten der NAV-Versionen im Überblick

Alle Daten stammen aus den Lifecycle-Seiten von Microsoft und gelten in Pazifikzeit (Microsoft Lifecycle). NAV 2017 trägt intern die Versionsnummer 10 (Microsoft Learn). Wer auf NAV 2018 arbeitet, hat ein Jahr mehr Zeit. Bemerkenswert ist die letzte Zeile: Business Central 14, die erste Station auf dem Weg von NAV zu einer aktuellen Version, ist selbst seit Oktober 2025 ohne Support (Microsoft Lifecycle). Sie taugt also nur als Zwischenschritt, nicht als Ziel.

Warum die Shop-Anbindung der kritische Teil ist

In Dynamics NAV laufen Shop-Anbindungen in der Regel über Webdienste. NAV bietet OData-Webdienste zusätzlich zu den SOAP-Webdiensten, die es seit Dynamics NAV 2009 gibt (Microsoft Learn). Veröffentlicht werden Seiten und Codeunits: Seiten liefern Artikel, Bestände oder Debitoren, Codeunits kapseln Abläufe wie den Auftragsimport. Codeunits lassen sich in NAV nicht über OData ansprechen (Microsoft Learn), deshalb hängen gerade Bestellimporte oft an SOAP. Angemeldet wird mit Benutzername und Kennwort oder mit einem Web-Service-Zugriffsschlüssel, sofern der Server nicht auf Windows-Anmeldung eingestellt ist (Microsoft Learn).

Business Central übernimmt diese Technik nicht unverändert. SOAP gilt dort als von OData V4 abgelöst, und Microsoft empfiehlt, Integrationen so bald wie möglich auf OData V4 umzustellen (Microsoft Learn). OData V3 ist seit Business Central 2021 release wave 1 entfernt (Microsoft Learn). Ab Version 29.0, also mit 2026 release wave 2, lassen sich Microsoft-Seiten nicht mehr als SOAP-Endpunkt veröffentlichen (Microsoft Learn). Ab Version 30, die mit 2027 release wave 1 erscheinen soll, gilt dasselbe für OData-Endpunkte (Microsoft Learn). Microsoft-Seiten sind alle Seiten aus Apps des Herausgebers Microsoft, darunter die Base Application. Wer solche Seiten weiter als Endpunkt braucht, muss sie laut Microsoft in eine eigene Erweiterung kopieren.

Eine UI-Seite ist keine API. Änderungen an ihr können deshalb in einem Release erfolgen, ohne als Breaking Change zu gelten.

Microsoft Learn, Deprecated features in the platform (eigene Übersetzung)

Hinzu kommt die Anmeldung. In Business Central online funktionieren Integrationen, die sich mit einem Web-Service-Zugriffsschlüssel (Basic Auth) anmelden, nach dem 1. Oktober 2022 nicht mehr, OAuth2 ist dort die einzige Anmeldeart (Microsoft Learn). Für Business Central on-premises bleibt der Zugriffsschlüssel vorerst eine Option. Auch die Schnittstellenversion hat sich bewegt: Die Standard-API v1.0 ist mit Version 28.0 entfallen, aktuell ist API v2.0 (Microsoft Learn). Eine Shop-Anbindung, die heute neu entsteht, setzt deshalb auf API v2.0 und OAuth, nicht auf veröffentlichte UI-Seiten. Wer bereits eine Middleware-Schicht zwischen Shop und ERP betreibt, tauscht nur deren ERP-Seite; wer den Shop direkt mit NAV verbunden hat, baut die Verbindung neu.

Alte und neue Anbindung im Vergleich

Die Tabelle zeigt, warum ein bloßes Umstecken der Adresse selten reicht. Fast jede Zeile verlangt eine Entscheidung in der Anbindung: neue Schlüssel, eine neue Anmeldung, ein neues Verfahren für Änderungen und eine Fehlerbehandlung, die mit den Grenzen je Nutzer umgehen kann. Höchstens 5 OData-Anfragen verarbeitet Business Central online je Nutzer gleichzeitig; weitere warten in einer Warteschlange, und nach 8 Minuten Wartezeit bricht eine Anfrage mit Status 503 ab (Microsoft Learn). Wie Batch-Anfragen und Wiederholungslogik darauf antworten, zeigt unser Beitrag zur Business-Central-Anbindung.

Welche Wege von NAV 2017 zu Business Central führen

Einen direkten Sprung von NAV 2017 in die Cloud gibt es nicht. Wer heute auf einer NAV-Version arbeitet, muss zuerst auf Business Central on-premises aktualisieren und kann erst danach zu Business Central online wechseln (Microsoft Learn). Beide Wege in die Cloud beginnen mit dem Upgrade auf Business Central Version 14 (Microsoft Learn). Für den Weg zur aktuellen Version nennt Microsoft für NAV 2017 eine Kette über Zwischenstände:

1. Upgrade von NAV 2017 auf Business Central Spring 2019, Version 14. Dabei wird die Anwendung von C/AL auf AL umgestellt (Microsoft Learn).
2. Upgrade von Version 14 auf Business Central 2024 release wave 2, Version 25. Ein direkter Schritt von Version 14 auf die neueren Versionen wird seit Version 26 nicht mehr unterstützt (Microsoft Learn).
3. Upgrade von Version 25 auf die Zielversion on-premises, derzeit Version 29 aus 2026 release wave 2 (Microsoft Learn).
4. Auf Wunsch der Wechsel zu Business Central online mit dem Werkzeug für die Cloud-Migration, das ab Version 25 direkt möglich ist (Microsoft Learn).

Für den Weg in die Cloud unterscheidet Microsoft zwei Varianten. Die vollständige Migration übernimmt alle Daten und Anpassungen und setzt voraus, dass C/AL-Anpassungen in AL-Erweiterungen umgebaut werden (Microsoft Learn). Die Neuimplementierung mit dem Business Central 14 Reimplementation Tool übernimmt nur Stammdaten, Salden, einen Teil der gebuchten Historie und Einrichtungsdaten und kommt dafür ohne Umbau der Anpassungen aus (Microsoft Learn); Microsoft führt das Werkzeug derzeit als Vorschau.

Wer on-premises bleibt, wechselt das Lebenszyklusmodell. Business Central on-premises ab 2019 release wave 2 fällt unter die Modern Lifecycle Policy, und Microsoft unterstützt die Software nur, wenn der Betrieb sie aktuell hält (Microsoft Learn). Version 29 etwa, erschienen im Oktober 2026, wird bis April 2028 unterstützt (Microsoft Lifecycle). Statt eines großen Upgrades alle paar Jahre stehen also regelmäßige Aktualisierungen an, und jede davon trifft auch die Shop-Schnittstelle.

Die neue Schnittstelle: API v2.0, OAuth und Webhooks

Business Central stellt für Integrationen Standard-APIs bereit, die sich über REST aus jeder Programmiersprache ansprechen lassen (Microsoft Learn). In API v2.0 tragen die Datensätze eindeutige GUID-Schlüssel und lassen sich über die unveränderliche SystemId abrufen (Microsoft Learn). Das hat Folgen für den Umzug: Der Shop kennt Artikel und Kunden bisher über NAV-Nummern, künftig braucht er zusätzlich die SystemId, oder die Anbindung übersetzt zwischen beiden. Standard-APIs lassen sich nicht um zusätzliche Felder erweitern. Wer Felder braucht, die NAV über eine angepasste Seite geliefert hat, kopiert die API in eine eigene API-Seite und ergänzt sie dort (Microsoft Learn). Wie eine Anbindung an ein bereits laufendes Business Central im Detail aussieht, beschreibt unser Beitrag zur Anbindung von Business Central an Shopware.

Für die Anmeldung empfiehlt sich bei einer Shop-Anbindung ein Anwendungskonto statt eines persönlichen Benutzerkontos. Microsoft unterscheidet zwischen der Anmeldung im Namen eines Benutzers, die einen interaktiv angemeldeten Benutzer voraussetzt, und der Dienst-zu-Dienst-Anmeldung einer Anwendung (Microsoft Learn). Die Anwendung wird in Microsoft Entra ID registriert und erhält Zugriffstoken, ohne dass jemand am Bildschirm sitzt. Berechtigungen vergibt man so eng wie möglich: Die Anbindung liest Artikel, Bestände und Preise und legt Aufträge an, mehr nicht.

Einen spürbaren Unterschied im Alltag machen Webhooks. Statt im Takt nachzufragen, ob sich Bestände geändert haben, abonniert die Anbindung Änderungsmeldungen. Business Central sendet sie nicht sofort, sondern wartet nach der ersten Änderung an einem Datensatz standardmäßig 30 Sekunden (Microsoft Learn). Werden in dieser Zeit mehr als 1.000 Datensätze geändert, kommt eine Sammelmeldung statt einzelner Meldungen (Microsoft Learn). Ein Abo läuft nach drei Tagen ab, wenn es nicht vorher erneuert wird (Microsoft Learn). Wie man solche Ereignisse im Shop sauber verarbeitet, beschreibt unser Beitrag zur Webhook-Architektur. Ein Abo für Artikeländerungen legt die Anbindung etwa so an:

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

Beim Anlegen und bei jeder Erneuerung prüft Business Central die Zieladresse: Sie muss das mitgeschickte validationToken im Antworttext mit Status 200 zurückgeben (Microsoft Learn). Erreicht Business Central den Empfänger nicht, versucht es die Zustellung über die folgenden 36 Stunden erneut (Microsoft Learn). Das gilt allerdings nur, wenn der Empfänger mit 408, 429 oder einem Fehler im Bereich 500 bis 599 antwortet; bei jedem anderen Code wird das Abo gelöscht (Microsoft Learn). Ein Erneuerungsjob und ein Abgleich im Takt als Rückfallebene gehören deshalb zur Anbindung.

Parallelbetrieb: Bestellungen dürfen nicht liegen bleiben

Der heikelste Moment eines ERP-Wechsels ist für den Shop die Umschaltung. Bewährt hat sich ein Aufbau, in dem der Shop Bestellungen nicht direkt ins ERP schreibt, sondern in eine Warteschlange legt, aus der die Anbindung sie abholt. Steht das ERP für einige Stunden still, sammeln sich die Aufträge dort, statt verloren zu gehen. Jeder Auftrag trägt die Bestellnummer des Shops als externe Belegnummer, damit ein doppelter Import auffällt, wenn ein Auftrag nach der Umschaltung ein zweites Mal ankommt.

1. Bestandsaufnahme: Welche Webdienste veröffentlicht NAV 2017, welche davon nutzt der Shop, in welche Richtung, wie oft und mit welchem Konto?
2. Abbildung: Für jedes Feld der alten Schnittstelle steht fest, woher es in Business Central kommt: Standard-API, eigene API-Seite oder Berechnung in der Anbindung.
3. Neue Anbindung gegen eine Sandbox: Die Schnittstelle entsteht gegen eine Business-Central-Sandbox und wird dort mit Testbestellungen geprüft.
4. Probelauf: Microsoft empfiehlt mindestens einen vollständigen Probelauf der Migration in einer Sandbox vor der Umschaltung (Microsoft Learn); die Shop-Anbindung läuft dabei mit.
5. Schattenbetrieb: Die neue Anbindung liest Bestände und Preise aus Business Central, schreibt aber noch nichts. Ein Vergleich mit NAV zeigt Abweichungen, bevor Kunden sie sehen.
6. Umschaltung: Bestellübergabe anhalten, letzte Aufträge in NAV abschließen, Daten übernehmen, Anbindung umstellen, Warteschlange freigeben.
7. Nachlauf: Aufträge, Bestände und Zahlungsstatus zwischen Shop und Business Central abgleichen und die Schnittstelle überwachen.

Dass die Integrationen zum Migrationsplan gehören, steht auch in Microsofts eigenem Fahrplan: Für die Zeit nach der Migration nennt Microsoft ausdrücklich das Wiederverbinden der Integrationen, zusammen mit dem Freischalten der Benutzer und der Überwachung der Umgebung (Microsoft Learn). Im Projektplan sollte die Shop-Anbindung deshalb ein eigener Arbeitsstrang mit eigenem Test sein, nicht ein Punkt auf der Abnahmeliste des ERP-Projekts. Für einen Echtzeit-Bestandsabgleich über mehrere Kanäle gilt das umso mehr, weil dort jede Verzögerung als Überverkauf sichtbar wird.

Bestandsaufnahme: Was die alte Anbindung heute leistet

Viele Überraschungen beim Umzug stammen aus Aufgaben, die die alte Anbindung still miterledigt hat. Oft wurde sie über Jahre erweitert, ohne dass jemand die Liste ihrer Aufgaben führt. Eine Bestandsaufnahme vor dem ersten Entwurf spart deshalb Zeit. Diese Fragen sollte sie beantworten:

• Welche Seiten und Codeunits sind in NAV als Webdienst veröffentlicht, und welche davon ruft der Shop tatsächlich auf?
• Wie meldet sich der Shop an: mit Benutzername und Kennwort, mit Zugriffsschlüssel oder über ein Windows-Konto?
• Welche eigenen Felder überträgt die Schnittstelle, etwa Zusatzangaben zu Artikeln, Lieferbedingungen oder Kundengruppen?
• Wie entstehen Debitoren: Legt der Shop neue Kunden in NAV an, oder ordnet er Bestellungen bestehenden Kunden zu?
• Woher kommen kundenspezifische Preise und Staffeln, und wie oft werden sie abgeglichen?
• Wer meldet Versandstatus und Sendungsnummern an den Shop zurück, und auf welchem Weg?
• Was passiert bei einem Fehler: Gibt es Wiederholungen, Protokolle und eine Benachrichtigung?
• Welche weiteren Quellen schreiben Aufträge ins ERP, etwa Bestellungen per Mail oder PDF, die über eine KI-Auftragserfassung laufen?

Aus den Antworten entsteht eine Abbildungstabelle mit alter Quelle, neuem Ziel, Umrechnung und Verantwortlichem. Sie ist die Grundlage für die Entwicklung und später für die Abnahme. Bei B2B-Shops mit Kundengruppen, Rahmenpreisen und Freigaben wird sie erfahrungsgemäß deutlich länger als bei reinen Endkundenshops; welche Anforderungen dort typischerweise hinzukommen, zeigt unsere Seite zum B2B-E-Commerce.

Zeitplan bis zum Supportende

Bis zum 11. Januar 2027 bleibt wenig Zeit, zumal der Dezember in vielen Betrieben mit Jahresabschluss und Inventur belegt ist. Ein vollständiger Umstieg auf Business Central samt neuer Shop-Anbindung lässt sich in dieser Zeit oft nicht mehr abschließen. Wichtig ist darum eine Reihenfolge, die das Risiko zuerst senkt:

• Sofort: Bestandsaufnahme der Schnittstelle und Entscheidung über den Zielweg, online oder on-premises.
• Vor dem Stichtag: NAV-Server und veröffentlichte Webdienste abschotten. Die Webdienste sollten nur für die Anbindung erreichbar sein, nicht offen im Internet stehen, und verschlüsselt über SSL laufen, wie Microsoft es bei Anmeldung mit Kennwort oder Zugriffsschlüssel empfiehlt (Microsoft Learn).
• Parallel: Die neue Anbindung gegen eine Sandbox bauen, damit sie bereitsteht, sobald das ERP-Upgrade die Zielversion erreicht.
• Nach dem Stichtag: Den Weiterbetrieb von NAV 2017 als befristete Ausnahme dokumentieren, mit einem festen Termin für die Umschaltung.

Wer gleichzeitig andere Termine im Blick behalten muss, findet sie im Fristenkalender 2027 für Onlineshops. Und wer seinen Shop auf Shopware 6.5 betreibt, hat mit dem Ende der Sicherheitsupdates für Shopware 6.5 eine zweite Frist kurz nach dem NAV-Stichtag. Beide Umstellungen lassen sich dann sinnvoll in einem gemeinsamen Plan ordnen, damit Shop und ERP nicht in derselben Woche umgebaut werden.

Typische Stolpersteine beim Schnittstellenumzug

• Abos laufen aus: Ein Webhook-Abo, das nicht erneuert wird, endet nach drei Tagen (Microsoft Learn), und Bestände werden dann still nicht mehr aktualisiert. Ein Überwachungsjob prüft das Ablaufdatum im Feld expirationDateTime.
• Drosselung unter Last: Bei Status 429 braucht die Anbindung eine Wiederholung mit Wartezeit (Microsoft Learn). Ohne sie gehen Aktualisierungen ausgerechnet in Spitzenzeiten verloren.
• Eigene Felder fehlen: Was eine angepasste NAV-Seite mitgeliefert hat, steht in keiner Standard-API. Das fällt oft erst im Test auf, wenn ein Feld im Shop leer bleibt.
• Filter verhalten sich anders: Schon NAV unterstützte in OData-Filtern keinen OR-Operator über verschiedene Felder (Microsoft Learn). Abfragen der alten Anbindung werden deshalb für die API neu geschrieben, statt sie unverändert zu übernehmen.
• Zwei Hauptupdates pro Jahr: In Business Central online kommen neue Hauptversionen im April und im Oktober (Microsoft Learn). Die Anbindung gehört vor jedem Update in einer Vorschau-Sandbox getestet, die Microsoft etwa einen Monat vor dem Update bereitstellt (Microsoft Learn).
• Überwachung fehlt: Eine Schnittstelle, die nachts still ausfällt, bemerkt man am nächsten Morgen an Kundenanfragen. Die Überwachung von Warteschlange, Fehlern und Abo-Status gehört zum Umzug, ähnlich wie beim Shop-Monitoring für Verfügbarkeit und Ladezeit.

So unterstützen wir den Umzug der Shop-Anbindung

Wir verbinden Onlineshops mit Dynamics NAV und Business Central, online wie on-premises, und arbeiten auf beiden Seiten der Schnittstelle. Den ERP-Wechsel selbst begleitet in der Regel ein Microsoft-Partner; wir konzentrieren uns auf den Teil, an dem das Tagesgeschäft im Shop hängt, und stimmen ihn mit dem ERP-Projekt ab.

Wenn noch offen ist, welcher Weg für Ihr Unternehmen passt, klären wir das in einer Beratung: Ausgangslage, Zielsystem, Zeitplan und die Frage, was bis zum 11. Januar 2027 realistisch erreichbar ist. Einen Überblick über weitere ERP- und Marktplatzanbindungen gibt unsere Seite zu den Schnittstellen.