- UPDATE STRATEGIEN Business Central – Teil 1 –
- Warum die Frage heute auf den Tisch gehört
- Warum es nicht nur um ein Upgrade geht
- Was sich auf dem Weg in eine moderne Business-Central-Version tatsächlich ändert
- Typische Bruchstellen in gewachsenen NAV-Landschaften
- Wie ein tragfähiges Zielbild aussieht
- Drei grundsätzliche Wege zu diesem Ziel
- Warum die richtige Wahl immer von Ihrer Ausgangslage abhängt
- Unser Fazit
UPDATE STRATEGIEN Business Central – Teil 1 –
In unserer Blog-Serie beleuchten wir die strategischen Handlungsoptionen, um von Dynamics NAV bzw. älteren Business-Central-Versionen hin zu einer aktuellen Business-Central-Version zu gelangen. Wir ordnen die verschiedenen Strategien ein, beleuchten Chancen und Risiken und zeigen Ihnen, worauf es bei einer tragfähigen Entscheidung in der Praxis ankommt.
Ausgangslage & Zielbild: Wie kommen wir von Dynamics NAV auf eine aktuelle Business-Central-Version?
Viele Unternehmen stehen heute vor einer vertrauten Situation: Das bestehende NAV-System läuft, die Prozesse sind eingespielt, und im Lauf der Jahre wurde vieles so ergänzt, dass es zur eigenen Organisation passt. Gerade deshalb wird die Frage nach dem weiteren Weg oft lange vertagt. Solange das System fachlich trägt, wirkt ein Wechsel schnell wie ein technisches Thema, das man auch später noch angehen kann.
Genau darin liegt aber die eigentliche Herausforderung. Der Weg von Dynamics NAV auf eine aktuelle Business-Central-Version ist in vielen Fällen deutlich mehr als ein klassisches Upgrade. Für Ihr Unternehmen geht es nicht nur um eine neue Versionsnummer, sondern um die Frage, wie tragfähig, wartbar und veränderbar das bestehende ERP-System künftig noch sein soll. In diesem ersten Beitrag schauen wir deshalb bewusst auf die Ausgangslage und auf das Zielbild. Außerdem ordnen wir für Sie die drei grundsätzlichen Handlungsoptionen erstmals ein: Legacy Run, Brownfield Upgrade und Greenfield Reimplementation.
Warum die Frage heute auf den Tisch gehört
Viele NAV-Systeme sind über Jahre oder sogar Jahrzehnte gewachsen. Sie wurden erweitert, stabilisiert und immer wieder an neue fachliche Anforderungen angepasst. Genau das macht sie im Alltag oft leistungsfähig. Gleichzeitig sorgt gerade diese Entwicklung dafür, dass der Weg auf eine aktuelle Business-Central-Version heute sorgfältig geplant werden muss.
Besonders deutlich wird das bei Business Central Spring 2019 (Version 14), kurz BC 14. Diese Version markiert eine technische und fachliche Schwelle, weil sie die letzte Version mit C/AL und zugleich die letzte Version mit Windows-Client ist. Wer von dort auf eine aktuelle Business-Central-Version wechselt, bewegt sich also nicht einfach von einer älteren in eine neuere Versionsstufe, sondern in ein anderes Entwicklungs- und Betriebsmodell.
Für Ihr Unternehmen verschiebt sich damit auch der Blick auf die eigentliche Aufgabe. Entscheidend ist nicht mehr nur, ob das bestehende System heute noch funktioniert. Entscheidend ist, wie belastbar es für die nächsten Jahre aufgestellt ist. Wie gut lässt es sich weiter pflegen? Welche Risiken entstehen durch gewachsene Sonderlogik? Und wie realistisch ist es, mit vertretbarem Aufwand in einen tragfähigen Zielzustand zu kommen?
Gerade in langjährig gewachsenen ERP-Landschaften liegt hier der Kern der Entscheidung. Viele Bestandslösungen wurden über Jahre weiterentwickelt, ohne dass jede Anpassung, jede Integration und jede technische Abhängigkeit grundsätzlich hinterfragt wurde. Das ist nachvollziehbar. Es macht die Ausgangslage für eine Modernisierung aber nicht einfacher.
Warum es nicht nur um ein Upgrade geht
In vielen Projekten beginnt die Diskussion mit der Zielversion. Das ist naheliegend, greift aber zu kurz. Denn der Wechsel von Dynamics NAV auf eine aktuelle Business-Central-Version ist in der Regel kein bloßer technischer „Lift & Shift“ des bestehenden Systems.
Tatsächlich geht es um ein neues Zielbild. Historische NAV-Lösungen sind häufig durch individuelle Standardmodifikationen, technische Nähe zur Infrastruktur und über Jahre gewachsene Sonderlösungen geprägt. Vieles davon war zum Zeitpunkt der Einführung absolut sinnvoll. Problematisch wird es erst dann, wenn diese Strukturen stillschweigend als gesetzt behandelt werden, obwohl die aktuelle Business-Central-Welt andere Leitplanken setzt.
Genau hier beginnt die eigentliche Modernisierungsaufgabe. Es reicht nicht, nur zu klären, wie das bestehende System in eine aktuelle Version überführt werden kann. Ebenso wichtig ist die Frage, welche Teile der bestehenden Lösung fachlich unverzichtbar, technisch tragfähig und langfristig sinnvoll sind. Wer diese Unterscheidung zu spät trifft, macht aus einem beherrschbaren Vorhaben schnell ein schwer steuerbares Projekt.
Was sich auf dem Weg in eine moderne Business-Central-Version tatsächlich ändert
Der Wechsel auf eine aktuelle Business-Central-Version bringt nicht nur neue Funktionen mit sich. Er verändert auch die technischen Spielregeln. Anpassungen am Standard müssen in aktuellen Business-Central-Versionen in eigene Apps bzw. Standard-Extensions überführt werden. Gleichzeitig stoßen klassische Alttechniken wie .NET-Komponenten, Dateioperationen, lokale Drucklogik, direkte SQL-Zugriffe oder bestimmte Client-Erweiterungen insbesondere im SaaS-Modell an Grenzen – im OnPrem-Betrieb können einige Muster weiterhin technisch möglich sein, sind aber häufig architektonisch nachteilig.
Für die Praxis ist das ein wichtiger Punkt. Der Aufwand eines Modernisierungsvorhabens hängt häufig nicht an der Anzahl der Anpassungen, sondern an ihrer Art. Zehn kleinere funktionale Besonderheiten sind oft leichter zu beherrschen als wenige technische Altlasten, die tief mit Infrastruktur, Clients oder Umsystemen verzahnt sind.
Genau deshalb lohnt sich an dieser Stelle ein nüchterner Blick auf die eigene Systemrealität: Welche individuellen Lösungen sind tatsächlich geschäftskritisch? Welche sind eher historisch gewachsen? Wo bestehen technische Abhängigkeiten, die in einer aktuellen Business-Central-Version nicht mehr ohne Weiteres fortgeführt werden können? Und wo ist der Standard heute deutlich stärker, als es zum Zeitpunkt der ursprünglichen Einführung der Fall war?
Aus unserer Sicht gibt es einige wiederkehrende Muster, die Unternehmen auf dem Weg in eine aktuelle Business-Central-Version besonders genau prüfen sollten.
1. Bereich: Anpassungen am Standard
Was früher oft der pragmatischste Weg war, ist heute häufig genau der Teil, der den Weg in die Zukunft erschwert. Wenn individuelle Logik tief in Standardobjekten verankert ist, steigen Analyse-, Umbau- und Testaufwand erheblich.
2. Bereich: Technische Abhängigkeiten
Direkte SQL-Anbindungen, lokales File Handling, drucknahe Prozesse mit Infrastrukturbezug oder ältere .NET-Komponenten wirken in Bestandslösungen oft selbstverständlich. In der Modernisierung werden sie jedoch schnell zu Risikotreibern.
3. Bereich: Historisch gewachsene Fachlogik
Gerade in ERP-Systemen steckt viel Wissen nicht nur in Dokumentationen, sondern im Verhalten des Systems selbst. Das macht Modernisierung anspruchsvoll. Denn nicht jede individuelle Funktion ist automatisch strategisch wertvoll. Manche ist unverzichtbar, andere lediglich vertraut. Für Ihre Entscheidung ist genau diese Unterscheidung zentral.
Hinzu kommt ein vierter Punkt, der häufig unterschätzt wird: Viele Besonderheiten eines Systems sind nicht nur technisch entstanden, sondern organisatorisch gewachsen. Workarounds, Zusatzlogiken und Sonderprozesse spiegeln oft Entscheidungen wider, die zu einem bestimmten Zeitpunkt sinnvoll waren. Bei der Modernisierung sollten diese Themen nicht automatisch fortgeschrieben, sondern bewusst bewertet werden
Wie ein tragfähiges Zielbild aussieht
Wenn wir in dieser Blog-Serie von einer aktuellen Business-Central-Version als Ziel sprechen, meinen wir deshalb nicht einfach ein erfolgreiches Go-live auf einem neuen Release. Gemeint ist ein System, das fachlich trägt und technisch so aufgestellt ist, dass Ihr Unternehmen auch künftige Änderungen, Erweiterungen und Updates besser beherrschen kann.
Ein tragfähiges Zielbild hat aus unserer Sicht vier wesentliche Merkmale.
Erstens: mehr Standardnähe. Nicht jede alte Abweichung vom Standard ist heute noch notwendig. Gerade in gewachsenen NAV-Landschaften lohnt sich die Frage, ob aktuelle Standardfunktionen Anforderungen inzwischen sauberer abdecken als historische Eigenlösungen.
Zweitens: sauber getrennte Erweiterungen. Individuelle Anforderungen sollten möglichst klar abgegrenzt und nicht als schwer durchschaubare Eingriffe in den Standard organisiert sein. Sie sollten in eine extension-basierte Architektur überführt werden, um Updatefähigkeit und Wartbarkeit zu sichern.
Drittens: weniger technische Sonderabhängigkeiten. Je stärker ein System auf lokale Ressourcen, direkte Datenbankzugriffe oder historisch gewachsene Spezialtechnik angewiesen ist, desto schwieriger wird die künftige Update- und Betriebsfähigkeit.
Viertens: realistische Änderungs- und Testfähigkeit. Zukunftsfähigkeit ist nicht nur eine Frage der Zielversion, sondern auch der Art und Weise, wie Änderungen umgesetzt, getestet und langfristig abgesichert werden. Ein System ist nicht deshalb zukunftsfähig, weil es einmal erfolgreich auf eine neue Version gehoben wurde. Zukunftsfähig ist es dann, wenn spätere Änderungen kontrolliert und wiederholbar möglich bleiben.
Das Ziel ist also nicht einfach ein Versionswechsel. Das Ziel ist eine ERP-Landschaft, die sich nach dem Projekt besser betreiben, besser erweitern und besser weiterentwickeln lässt als zuvor.
Drei grundsätzliche Wege zu diesem Ziel
Aus dieser Ausgangslage ergeben sich aus unserer Sicht drei strategische Handlungsoptionen.
Legacy Run (Erhaltungsbetrieb)
Beim Legacy Run wird die bestehende Lösung weiterbetrieben, mit möglichst wenigen Änderungen. Im Vordergrund stehen Stabilisierung, Wartung und Risikobegrenzung, aber keine grundlegende Modernisierung.
Legacy Run kann sinnvoll sein, wenn Ihr Unternehmen bewusst Zeit gewinnen will. Er ist aber kein Dauerzustand, sondern ein gesteuerter Erhaltungsbetrieb mit klaren Grenzen. Je länger dieser Weg gewählt wird, desto wichtiger werden ein bewusster Umgang mit Risiken und ein realistischer Blick auf die verbleibende Zukunftsfähigkeit des Systems.
Brownfield Upgrade (In-Place Modernisierung)
Beim Brownfield Upgrade wird das bestehende System mit Code und Daten auf eine aktuelle Business-Central-Version weiterentwickelt. Dieser Weg ist häufig der pragmatischste, weil Prozesse, Datenhistorie und bekannte Systemlogiken weitgehend erhalten bleiben.
Brownfield ist damit oft ein realistischer Weg, aber nicht automatisch der einfache. Gerade technische Altlasten und historisch gewachsene Sonderlösungen müssen auch hier sauber eingeordnet und bearbeitet werden. Der Vorteil liegt meist in der höheren Kontinuität, der Nachteil oft darin, dass bestehende Komplexität teilweise mitgenommen wird.
Greenfield Reimplementation (Neuimplementierung)
Bei der Greenfield Reimplementation wird nicht das bestehende System technisch fortgeschrieben, sondern eine aktuelle Business-Central-Version als neues Standardsystem aufgebaut. Benötigte Funktionen werden gezielt neu umgesetzt, Daten selektiv übernommen.
Greenfield ist damit häufig der sauberste Weg, verlangt aber die größte Disziplin bei Scope, Priorisierung und organisatorischer Veränderung. Der Gewinn liegt vor allem in der Chance, technische Schulden und historisch gewachsene Sonderwege konsequenter zu hinterfragen.
Warum die richtige Wahl immer von Ihrer Ausgangslage abhängt
An dieser Stelle wäre es bequem, sofort eine Rangfolge aufzumachen. Greenfield sei langfristig am besten, Brownfield am pragmatischsten und Legacy Run nur eine Übergangslösung. Ganz falsch wäre das nicht. Für eine seriöse Entscheidung reicht diese Vereinfachung aber nicht aus.
Die richtige Strategie hängt immer von Ihrer konkreten Ausgangslage ab. Dazu gehören unter anderem der tatsächliche Grad des Customizings, die Art und Kritikalität vorhandener Integrationen, die Bedeutung historischer Daten, die Veränderungsbereitschaft im Unternehmen und die Frage, wie schnell wieder ein supportfähiger Zustand erreicht werden muss.
Gerade für IT-Leitung, ERP-Verantwortliche und Projektleiter liegt hier die eigentliche Führungsaufgabe: nicht vorschnell eine Technikentscheidung zu treffen, sondern zunächst die eigene Systemrealität sauber einzuordnen. Erst auf dieser Grundlage lässt sich sinnvoll entscheiden, welcher Weg für Ihr Unternehmen fachlich, technisch und organisatorisch tragfähig ist.
Unser Fazit
Der Weg von Dynamics NAV auf eine aktuelle Business-Central-Version beginnt nicht mit der Auswahl einer Zielversion. Er beginnt mit einem realistischen Blick auf Ihre Ausgangslage.
Für Ihr Unternehmen geht es dabei nicht nur um Technik, sondern um eine grundlegendere Frage: Wie tragfähig ist das bestehende ERP-System noch, wenn Sie nicht nur auf den heutigen Betrieb, sondern auf die nächsten Jahre schauen? Genau an diesem Punkt entscheidet sich, ob ein reiner Erhaltungsbetrieb noch verantwortbar ist, ob ein Brownfield Upgrade sinnvoll erscheint oder ob eine Greenfield Reimplementation langfristig die sauberere Option ist.
Aus unserer Sicht ist dabei vor allem eines wichtig: Behandeln Sie diese Entscheidung nicht als bloßes Upgrade-Thema. In vielen Fällen geht es um technische Tragfähigkeit, künftige Updatefähigkeit, den Umgang mit historisch gewachsenen Anpassungen und um ein Zielbild, das auch in einigen Jahren noch beherrschbar ist.
Wenn Sie sich aktuell mit den oben genannten Fragen beschäftigen und den Weg von Microsoft Dynamics NAV in eine aktuelle Microsoft Dynamics 365 Business Central-Version strukturiert angehen möchten, unterstützen wir Sie gerne – ob erste Einordnung Ihrer Ausgangslage, Bewertung der geeigneten Strategie oder konkrete Planung & Umsetzung Ihres Update-Projekts.
Mehr dazu erfahren Sie auf unserer Website oder im direkten Austausch mit uns:
Im nächsten Beitrag gehen wir den nächsten logischen Schritt und stellen Legacy Run, Brownfield Upgrade und Greenfield Reimplementation systematisch gegenüber. Dann schauen wir uns an, welche Entscheidungskriterien in der Praxis wirklich tragen und welche typischen Ausgangslagen eher für den einen oder den anderen Weg sprechen.
Bleiben Sie informiert und abonnieren Sie unseren PROTAKT Blog!
Über den Autor
DR. SVEN ODERMATT · EXECUTIVE BOARD
Vorstandsmitglied und Team Lead Technicals – mein Spielfeld: Development, DevOps und IT-Ops.
Ich kümmere mich seit 2002 um die Implementierung und den Betrieb von organisationsweiten Anwendungssystemen. Im NAV/Business-Central-Umfeld bin ich seit 2017 zuhause – mit Fokus auf einem zuverlässigen ERP-Betrieb und agilen Entwicklungsprozessen, die im Alltag wirklich funktionieren.
Platz für Deine Kommentare