Navision ERP – heute Microsoft Dynamics 365 Business Central

„Navision“ ist einer der bekanntesten ERP-Namen im Mittelstand. Heute heißt die Lösung Microsoft Dynamics 365 Business Central. Dieser Beitrag erklärt die Herkunft, die Einordnung als ERP-System und für wen sich die Lösung eignet.

Von Navision zu Dynamics 365 Business Central

Navision entstand in Dänemark und wurde 2002 von Microsoft übernommen. Aus „Microsoft Business Solutions – Navision“ wurde später Microsoft Dynamics NAV und schließlich – als cloudfähige Nachfolgegeneration – Microsoft Dynamics 365 Business Central. Viele Anwender und Suchende verwenden den eingängigen Namen „Navision“ bis heute, auch wenn das aktuelle Produkt anders heißt.

Einordnung als ERP-System

Business Central ist ein vollwertiges ERP für kleine und mittlere Unternehmen. Es deckt Finanzen, Einkauf, Verkauf, Lager/Warenwirtschaft, Projekte und – je nach Ausbaustufe – Produktion ab. Als Teil der Microsoft-Welt integriert es sich eng mit Microsoft 365 (Outlook, Excel, Teams) und Power BI, was im Microsoft-Umfeld ein praktischer Vorteil sein kann.

Für wen eignet sich die Lösung?

• für den Mittelstand, der eine breite Standardlösung sucht,
• für Unternehmen, die bereits auf Microsoft 365 setzen,
• für Betriebe mit Bedarf an einem internationalen, verbreiteten Produkt mit großem Partnernetz.

Was Sie bei der Bewertung beachten sollten

Wie bei jedem ERP gilt: Der Name allein sagt wenig über die Eignung. Entscheidend ist die Passung zu Ihren Prozessen, der gewählte Implementierungspartner und die Gesamtkosten. Verschaffen Sie sich in einer Demo ein Bild und prüfen Sie den Funktionsumfang anhand Ihres Lastenhefts. Details zum Funktionsumfang unter Navision Software.

Die Geschichte hinter dem Namen

Die Wurzeln von Navision reichen bis in die 1980er-Jahre nach Dänemark, wo das Unternehmen Navision Software A/S eine kaufmännische Lösung für den Mittelstand entwickelte. Im Jahr 2002 übernahm Microsoft das Produkt und integrierte es in seine Unternehmenssoftware-Sparte. Aus „Microsoft Business Solutions – Navision” wurde über die Jahre Microsoft Dynamics NAV, das in vielen mittelständischen Betrieben zum festen Bestandteil der IT wurde. Mit dem Wandel hin zur Cloud führte Microsoft schließlich Dynamics 365 Business Central als Nachfolgegeneration ein, die denselben funktionalen Kern in einer modernen, cloudfähigen Architektur fortführt. Dass der ursprüngliche Name „Navision” bis heute im Sprachgebrauch und in Suchanfragen lebt, zeigt, wie stark sich die Marke eingeprägt hat.

Für Interessenten ist diese Historie mehr als eine Randnotiz. Sie erklärt, warum man unter dem Stichwort Navision heute Informationen zu einem aktuellen, weiterentwickelten Produkt findet. Wer einen bestehenden Navision- oder Dynamics-NAV-Altbestand betreibt, steht zudem oft vor der Frage eines Umstiegs auf Business Central. Ein solcher Wechsel ist technisch ein eigenes Projekt, eröffnet aber den Zugang zu laufenden Cloud-Updates und einer engeren Verzahnung mit dem Microsoft-Ökosystem.

Das Partnernetz als Erfolgsfaktor

Business Central wird in aller Regel nicht direkt von Microsoft, sondern über ein dichtes Netz zertifizierter Partner eingeführt. Diese Partner bringen Branchen-Know-how und ergänzende Lösungen mit. Die Wahl des richtigen Partners ist für den Projekterfolg oft wichtiger als die Software selbst, da er Konfiguration, Anpassung und Support verantwortet. Achten Sie deshalb auf Referenzen in Ihrer Branche und auf eine erreichbare, verlässliche Betreuung.

Business Central in der betrieblichen Praxis

In der Praxis wird Microsoft Dynamics 365 Business Central – der Nachfolger von Navision – in sehr unterschiedlichen Branchen eingesetzt, vom Handel über Dienstleistung bis zur Fertigung. Seine Stärke liegt in der breiten Standardabdeckung kaufmännischer Prozesse und in der engen Verzahnung mit der Microsoft-Welt. Wer ohnehin mit Outlook, Excel und Teams arbeitet, findet sich schnell zurecht, weil viele Vorgänge in dieser vertrauten Umgebung ablaufen. Für branchenspezifische Anforderungen sorgen Partnerlösungen, die den Standard gezielt erweitern.

Wie bei jedem ERP entscheidet jedoch nicht das Produkt allein über den Erfolg, sondern die Qualität der Einführung und die Passung zu den eigenen Abläufen. Eine Demo mit eigenen Praxisfällen und ein Abgleich mit dem Lastenheft sind deshalb unverzichtbar, bevor eine Entscheidung fällt.

Der Wechsel von Dynamics NAV zu Business Central

Viele Unternehmen betreiben noch ältere Navision- oder Dynamics-NAV-Installationen und stehen vor der Frage des Umstiegs. Ein solcher Wechsel ist kein bloßes Update, sondern ein eigenes Projekt: Daten und Anpassungen müssen übernommen, alte Sonderentwicklungen überprüft und gegebenenfalls durch moderne Erweiterungen ersetzt werden. Im Gegenzug eröffnet der Schritt den Zugang zu laufenden Cloud-Updates, einer modernen Oberfläche und der engeren Integration ins Microsoft-Ökosystem. Ob und wann sich der Umstieg lohnt, hängt vom Zustand des Altsystems, vom Umfang der Anpassungen und von den eigenen Zielen ab. Eine fundierte Einschätzung gelingt am besten gemeinsam mit einem erfahrenen Partner, der den Migrationsaufwand realistisch bewerten kann. Funktionsdetails finden Sie unter Navision Software.

Lizenzmodell und Partnerwahl

Business Central wird üblicherweise im Abonnement pro benannten Nutzer lizenziert, wobei zwischen vollwertigen Lizenzen und günstigeren Lizenzen für gelegentliche Nutzer unterschieden wird. Welche Edition – Essentials oder Premium – und welche Lizenzart passt, hängt von den Rollen und Aufgaben im Unternehmen ab. Da Microsoft Konditionen und Modelle gelegentlich anpasst, sollten der Lizenzbedarf und die Kosten stets auf Basis der aktuellen Angaben kalkuliert werden.

Mindestens ebenso wichtig wie die Lizenz ist die Wahl des Implementierungspartners. Business Central wird in aller Regel nicht direkt von Microsoft, sondern über ein Netz zertifizierter Partner eingeführt, die Konfiguration, Anpassung, Datenmigration, Schulung und Support verantworten. Die Qualität dieses Partners prägt den Projekterfolg oft stärker als das Produkt selbst. Achten Sie deshalb auf Referenzen in Ihrer Branche, auf nachvollziehbare Erfahrung mit Projekten Ihrer Größenordnung und auf eine erreichbare, verlässliche Betreuung. Ein Gespräch mit bestehenden Kunden des Partners gibt oft den ehrlichsten Eindruck. Die richtige Kombination aus passender Lizenz und kompetentem Partner ist die Grundlage für ein Projekt, das im Budget bleibt und im Alltag funktioniert.

Der Vorteil laufender Cloud-Updates

Ein wesentlicher Pluspunkt der aktuellen Generation Business Central gegenüber dem klassischen Navision ist das Modell laufender Updates in der Cloud. Statt seltener, aufwendiger Versionssprünge erhält das System regelmäßig kleinere Aktualisierungen, die neue Funktionen, Verbesserungen und Sicherheitsupdates mitbringen. Dadurch bleibt die Software dauerhaft aktuell, und das Unternehmen vermeidet die früher gefürchteten großen Migrationsprojekte. Voraussetzung ist allerdings, dass Anpassungen sauber über Extensions umgesetzt sind, damit Updates reibungslos durchlaufen. Für viele Unternehmen ist gerade diese Wartungsfreiheit ein Hauptgrund, von einer alten Navision-Installation auf die Cloud-Variante zu wechseln. Wichtig ist, sich auf den Rhythmus der Updates einzustellen und Neuerungen im Blick zu behalten, um ihren Nutzen aktiv zu erschließen, statt sie nur passiv über sich ergehen zu lassen.

Vom dänischen Navision zu Microsoft Dynamics 365

Der Name „Navision“ steht für eine der erfolgreichsten ERP-Linien für den Mittelstand. Ihre Entwicklung lässt sich in klaren Etappen nachzeichnen:

Wer heute nach „Navision ERP“ sucht, meint in aller Regel den aktuellen Nachfolger Microsoft Dynamics 365 Business Central. Die Grundidee – ein integriertes System für den Mittelstand – ist über alle Generationen erhalten geblieben.

Stärken und Grenzen im Überblick

Checkliste: Umstieg von Alt-Navision

• vorhandene Version und Anpassungen dokumentieren
• Daten bereinigen und Migrationsumfang festlegen
• Individualanpassungen auf Standard-Nähe prüfen
• passenden Microsoft-Partner mit Branchenerfahrung wählen
• Cloud- vs. On-Premise-Betrieb entscheiden

Die Versionslinie im Detail: von Navision Financials bis Business Central Wave 2

Wer heute mit Microsoft Dynamics 365 Business Central arbeitet, blickt auf eine der längsten ununterbrochenen Produktlinien im gesamten ERP-Markt zurück. Die Software, die heute als reiner Cloud-Dienst aus Microsoft-Rechenzentren ausgeliefert wird, trägt in ihren Grundstrukturen Entscheidungen, die in den 1980er Jahren in Dänemark getroffen wurden. Für Bestandskunden ist die genaue Versionslinie deshalb keine museale Anekdote, sondern eine handfeste Arbeitsgrundlage: Die Versionsbezeichnung entscheidet darüber, welcher Wartungsstand noch unterstützt wird, welcher Upgrade-Pfad technisch überhaupt gangbar ist und mit welchen Bruchstellen ein Umstieg verbunden ist. Dieser Abschnitt zeichnet die konkreten Produktversionen und ihre technischen Sprünge nach – von den ersten Buchhaltungsprogrammen über die Navision-Financials-Generation und die NAV-Jahre bis zum heutigen halbjährlichen Release-Wave-Modell.

Die produkthistorische Einordnung wird hier bewusst technisch geführt. Eine kompakte Gesamtgeschichte des Produkts und seiner Markenwechsel finden Sie an anderer Stelle auf dieser Seite zur Navision-ERP-Linie; dort liegt der Fokus auf der Marke. Hier geht es um die Versionen selbst und darum, welche Generation welche Architektur einführte.

Die Vorgeschichte: PC&C, PCPlus und das erste Navision

Die Wurzeln reichen in das Jahr 1984 zurück, als die dänischen Gründer von Personal Computing and Consulting (PC&C) ihr erstes Buchhaltungsprodukt für den damals noch jungen Personal Computer entwickelten. Daraus entstand 1985 das Programm PCPlus – eine reine Einzelplatz-Finanzbuchhaltung, die in der MS-DOS-Welt verankert war und noch keinerlei Mehrplatzbetrieb kannte. Der eigentliche konzeptionelle Durchbruch gelang 1987 mit der ersten Version, die den Namen Navision trug. Entscheidend war hier nicht der Funktionsumfang, sondern die Architektur: Navision war von Beginn an als Client/Server-Lösung ausgelegt. Mehrere Anwender konnten gleichzeitig auf einen gemeinsamen Datenbestand zugreifen – ein für ein PC-basiertes Buchhaltungsprodukt jener Zeit bemerkenswerter Schritt, der die spätere Eignung für den vernetzten Mehrbenutzerbetrieb im Mittelstand begründete.

Mit diesem Mehrbenutzer-Ansatz war die strategische Richtung gesetzt: ein integriertes System, das Finanzbuchhaltung, Lager und betriebliche Prozesse in einem Datenmodell zusammenführt. Damit verließ Navision früh den Status einer isolierten Buchhaltung und bewegte sich auf das zu, was man heute ein vollwertiges ERP-System nennt. Die proprietäre Datenbank und die enge Verzahnung von Anwendung und Daten prägten die Produktlinie über Jahrzehnte – und sind bis heute ein Grund dafür, dass Migrationen aus sehr alten Beständen besondere Sorgfalt erfordern.

Von Navision Software A/S über Damgaard zum Microsoft-Kauf

1995 firmierte das Unternehmen als Navision Software A/S und festigte damit seine Marktposition. In diese Phase fällt der Übergang in die Windows-Welt: Aus dem zeichenorientierten DOS-Produkt wurde ein grafischer Windows-Client, der dem Anwender erstmals eine fensterbasierte Oberfläche mit Maus-Bedienung bot. Dieser Schritt vom Terminal-Charakter zur grafischen Benutzeroberfläche war der erste der drei großen Technologiesprünge, die die Produktlinie bis heute kennzeichnen – die beiden anderen folgten Jahre später mit dem Web-Client und der Cloud.

2000 kam es zur Fusion mit dem dänischen Wettbewerber Damgaard, dessen Produkt Axapta in den Konzern eingebracht wurde. Aus dem Zusammenschluss ging Navision Damgaard hervor, später wieder Navision A/S. Diese Konstellation – zwei eigenständige ERP-Linien unter einem Dach – ist der Grund, warum Microsoft später zwei getrennte Mittelstands-ERP führte: das aus Navision hervorgegangene NAV und das aus Axapta entstandene AX. 2002 erwarb Microsoft das gesamte Unternehmen für rund 1,4 Milliarden US-Dollar. Damit wechselte die dänische Software in den Besitz des größten Softwarekonzerns der Welt – mit weitreichenden Folgen für Plattform, Vertriebsmodell und Weiterentwicklungstempo.

Navision Financials und Attain: die Reifephase der proprietären Plattform

Unter dem Produktnamen Navision Financials und später Navision Attain entwickelte sich die Lösung in den späten 1990er und frühen 2000er Jahren zu einem reifen, modular aufgebauten Mittelstands-ERP. Charakteristisch für diese Generation war die enge Einheit aus eigener Datenbank-Engine, der proprietären Programmiersprache C/AL und dem fest integrierten Entwicklungswerkzeug C/SIDE. Anpassungen wurden direkt im Objektmodell der Anwendung vorgenommen – ein Ansatz, der die Software extrem flexibel machte, aber zugleich die Grundlage für die später so aufwendigen Upgrades legte. Warum genau diese Architektur den Umstieg auf moderne Versionen bis heute prägt, behandelt der eigene Abschnitt zum Wechsel von C/AL zu AL-Extensions auf dieser Seite; hier ist nur festzuhalten, dass die Attain-Generation die technische DNA festschrieb, die alle folgenden Versionen erbten.

Die Financials- und Attain-Stände waren reine Windows-Client-Anwendungen ohne Web-Zugriff. Wer heute noch einen solchen Bestand betreibt – was im Mittelstand durchaus vorkommt – steht vor der Situation, dass kein direkter Upgrade-Pfad in eine aktuelle Cloud-Version existiert. Solche Sprünge erfordern in der Regel mehrstufige Migrationen über Zwischenversionen, was bei der Auswahl eines Modernisierungswegs früh eingeplant werden muss.

Das Rebranding 2005 und die NAV-Versionen

2005 erfolgte das Rebranding zu Microsoft Dynamics NAV. Aus Navision Attain wurde das Produkt, das die folgenden dreizehn Jahre die Linie tragen sollte. Die Versionsbezeichnungen folgten zunächst klassischen Release-Nummern und gingen dann auf Jahreszahlen über – ein Detail, das für Bestandskunden bei jeder Wartungs- und Supportfrage relevant ist, weil Microsoft den unterstützten Lebenszyklus je Version definiert.

NAV 4.0 markierte die erste große Generation unter dem neuen Markennamen und blieb architektonisch der klassischen Welt verhaftet: ein fetter Windows-Client, der direkt mit der Datenbank kommunizierte. Der eigentliche Bruch kam mit Dynamics NAV 2009. Diese Version führte zwei tiefgreifende Neuerungen ein, die das Produkt grundlegend umbauten:

• Die Three-Tier-Architektur trennte erstmals Datenbankschicht, eine zwischengeschaltete Anwendungs- bzw. Service-Schicht (NAV Service Tier) und die Präsentationsschicht voneinander. Die Geschäftslogik lief nicht mehr ausschließlich auf dem Client, sondern wanderte auf einen Server – die Voraussetzung für spätere Web- und Cloud-Szenarien.
• Der RoleTailored Client (RTC) löste die seitenorientierte Bedienung durch ein rollenbasiertes Oberflächenkonzept ab: Anwender sahen ein auf ihre Tätigkeit zugeschnittenes Rollencenter statt eines undifferenzierten Menübaums.

NAV 2009 ist damit der zweite der drei großen Technologiesprünge. Bemerkenswert ist, dass diese Version den klassischen Client zunächst noch parallel mitführte – es gab einen Übergangszustand, in dem beide Bedienkonzepte koexistierten. Für die Praxis bedeutet das: Ein NAV-2009-Bestand kann sehr unterschiedlich konfiguriert sein, je nachdem, ob bereits auf den RoleTailored Client umgestellt wurde. Diese Differenzierung ist bei jeder Migrations- und Implementierungsplanung sorgfältig zu prüfen.

Die folgenden Versionen NAV 2013, 2015, 2016, 2017 und 2018 entwickelten diese Three-Tier-Basis kontinuierlich weiter, statt sie erneut umzuwerfen. Die wichtigsten Stationen lassen sich so zusammenfassen:

Der entscheidende technische Einschnitt innerhalb der NAV-Jahre fiel mit NAV 2013: Hier entfiel der klassische Windows-Client endgültig, und der Web-Client hielt Einzug. Damit war der dritte große Technologiestrang – die browserbasierte Bedienung – im Produkt verankert, noch bevor die Cloud-Auslieferung kam. Die Versionen 2015 und 2016 ergänzten Tablet-Unterstützung und führten erste Ansätze entkoppelter Erweiterungen ein, die später unter dem Namen AL-Extensions zum verbindlichen Modell wurden. NAV 2017 und 2018 schließlich brachten eine engere Verzahnung mit Office 365 und gelten als die unmittelbaren Vorgänger von Business Central.

Der Übergang zu Business Central 2018 und das Release-Wave-Modell

2018 beendete Microsoft die NAV-Linie als eigenständige Marke und führte das Produkt unter dem neuen Namen Microsoft Dynamics 365 Business Central fort. Dies war weit mehr als ein Markenwechsel: Business Central wurde von Beginn an als Software-as-a-Service (SaaS) konzipiert, die als gehosteter Cloud-Dienst aus Microsoft-Rechenzentren bezogen werden kann – der dritte und vorerst letzte der großen Technologiesprünge, vom On-Premises-Server in die echte Cloud. Technisch baute Business Central direkt auf der NAV-2018-Codebasis auf, sodass die Produktkontinuität trotz des neuen Namens gewahrt blieb. Welche Konsequenzen die Wahl zwischen Cloud, On-Premises und Private Cloud hat, ist Gegenstand des eigenen Abschnitts zu den Betriebsmodellen auf dieser Seite und wird hier bewusst nicht vertieft.

Mit Business Central wechselte Microsoft das Auslieferungs- und Versionsmodell grundlegend. An die Stelle der lockeren Jahresversionen trat das feste Release-Wave-Modell mit zwei großen Major-Releases pro Jahr: Release Wave 1 im Frühjahr und Release Wave 2 im Herbst. Diese Waves werden durch laufende kleinere Service-Updates ergänzt, sodass die Cloud-Variante kontinuierlich auf einem aktuellen Stand gehalten wird. Das Modell entspricht der modernen Praxis kontinuierlich gepflegter Cloud-Dienste und unterscheidet sich fundamental von der früheren Welt, in der eine Version über Jahre hinweg unverändert in Betrieb blieb.

Für Bestandskunden hat dieser Modellwechsel zwei praktische Seiten. In der Cloud-Variante werden die Release Waves weitgehend automatisch eingespielt; der Aufwand verlagert sich von einem seltenen, großen Upgrade-Projekt hin zu einer kontinuierlichen Anpassung an halbjährliche Neuerungen. Wer hingegen eine On-Premises-Installation betreibt, muss die Waves bewusst übernehmen und bleibt für den Lebenszyklus selbst verantwortlich. In beiden Fällen gilt: Anpassungen müssen so gebaut sein, dass sie die regelmäßigen Updates überstehen – genau hier setzt das moderne Erweiterungskonzept an, das die alten C/AL-Eingriffe ablöst.

Die Versionsbezeichnung folgt heute dem Muster der Release Waves – etwa „2024 Release Wave 2“ – und gibt damit präzise an, auf welchem Funktions- und Wartungsstand ein System läuft. Das ist nicht nur für die interne Dokumentation wichtig, sondern auch für die Zusammenarbeit mit Dienstleistern: Ein ERP-Beratungspartner kann nur dann verlässlich planen, wenn die exakte Wave, das Betriebsmodell und der Stand der Erweiterungen bekannt sind. Die scheinbar bürokratische Versionsangabe ist damit der gemeinsame Bezugspunkt für Support, Releasefähigkeit und jede Form der Weiterentwicklung.

Warum die Versionslinie für Entscheidungen heute zählt

Die Zusammenschau der Stationen zeigt ein klares Muster: Drei Technologiesprünge strukturieren die gesamte Produktlinie – der Wechsel von der DOS- zur grafischen Windows-Oberfläche (ab 1995), die Einführung der Three-Tier-Architektur mit Service-Schicht und Web-Client (ab NAV 2009 und NAV 2013) sowie der Schritt in die SaaS-Cloud mit halbjährlichen Release Waves (ab Business Central 2018). Jeder dieser Sprünge zog eine technische Grenzlinie ein, an der ein Upgrade nicht mehr ein bloßes Versionsincrement, sondern ein echter Plattformwechsel ist.

Für die Praxis heißt das: Die Frage „Welche Version setzen wir ein?“ ist immer auch die Frage „Welcher Sprung steht uns bevor?“. Ein Bestand auf NAV 2018 lässt sich vergleichsweise geradlinig nach Business Central überführen, weil die Codebasis verwandt ist. Ein Bestand auf NAV 2009 oder gar aus der Attain-Generation hingegen erfordert mehrstufige Migrationen, das Neuschreiben von Anpassungen und eine grundsätzliche Entscheidung über das künftige Betriebsmodell. Diese Einschätzung ist der erste Schritt jeder Modernisierung und sollte Teil einer strukturierten ERP-Auswahl sein, bei der die vorhandene Versionslinie, die Anpassungstiefe und die strategischen Ziele gemeinsam betrachtet werden. Die Versionslinie ist somit kein historisches Beiwerk, sondern die Landkarte, auf der jeder konkrete Upgrade- und Wartungsweg eingezeichnet ist.

Essentials, Premium und Team Member: die Editionen als Entscheidungsmatrix

Sobald die grundsätzliche Entscheidung für Microsoft Dynamics 365 Business Central gefallen ist, verschiebt sich die eigentliche Lizenzfrage auf eine konkrete und folgenreiche Ebene: Welche Edition wird welchem Mitarbeiter zugeordnet? Anders als bei vielen klassischen ERP-Produkten kauft man hier nicht ein monolithisches Komplettpaket und auch nicht beliebig zusammensteckbare Einzelmodule, sondern wählt pro Anwender zwischen drei klar definierten Lizenztypen: Essentials, Premium und Team Member. Diese drei SKUs unterscheiden sich nicht in Nuancen, sondern in der grundlegenden Frage, welche betrieblichen Funktionsbereiche ein Anwender überhaupt nutzen darf und ob er schreibend oder nur lesend in das System eingreift. Wer diese Logik nicht von Anfang an versteht, riskiert entweder eine teure Überlizenzierung oder eine Unterlizenzierung, die im laufenden Betrieb zu blockierten Prozessen führt.

Dieser Abschnitt geht deshalb bewusst tiefer als die allgemeine Einordnung des Lizenzmodells. Es geht hier nicht um die kaufmännische Mechanik von Abonnements oder die Frage Cloud gegen On-Premises, sondern ausschließlich um die inhaltliche Gegenüberstellung der drei Editionen: welcher Funktionsumfang in welcher Lizenz steckt, welche Nutzerrolle typischerweise zu welcher Edition passt und wie sich die drei Typen sinnvoll mischen lassen. Wer die strukturellen Anforderungen seines Betriebs zuvor in einer sauberen ERP-Auswahl erfasst hat, kann die hier beschriebene Matrix unmittelbar auf die eigenen Abteilungen und Rollen abbilden.

Essentials: der funktionale Kern für kaufmännische Vollnutzer

Die Edition Essentials bildet den funktionalen Grundstock von Business Central und deckt jene betriebswirtschaftlichen Prozesse ab, die in nahezu jedem Unternehmen vorkommen. Konkret umfasst Essentials die Finanzbuchhaltung mit Hauptbuch, Debitoren- und Kreditorenbuchhaltung, Bankabstimmung und Anlagenverwaltung, den gesamten Verkaufsprozess von der Angebotserstellung über Aufträge bis zur Fakturierung, den spiegelbildlichen Einkauf mit Bestellwesen und Lieferantenmanagement, die Lagerverwaltung und grundlegende Supply-Chain-Funktionen sowie das Projektmanagement mit Projektbuchung, Ressourcen und Zeiterfassung. Hinzu kommen CRM-nahe Funktionen für das Kontakt- und Verkaufschancenmanagement sowie ein Grundstock an Personalstammdaten.

Damit ist Essentials in den meisten Handels-, Dienstleistungs- und projektorientierten Unternehmen bereits die vollwertige Arbeitslizenz. Ein Anwender mit Essentials-Lizenz ist ein echter Vollnutzer: Er legt Belege an, bucht, ändert Stammdaten und steuert die kaufmännischen Kernprozesse mit vollem Schreibzugriff. Für ein Warenwirtschaftssystem im klassischen Sinne – also die durchgängige Steuerung von Einkauf, Lager und Verkauf – liefert Essentials bereits alle erforderlichen Bausteine. Genau deshalb ist diese Edition die Standardwahl für die kaufmännischen Vollarbeitsplätze in Buchhaltung, Vertriebsinnendienst, Einkauf, Disposition und Projektsteuerung.

Wichtig ist die Abgrenzung nach oben: Essentials enthält weder die produktionsbezogenen Funktionen noch das eigenständige Servicemanagement. Wer also eine reine Handels- oder Dienstleistungsorganisation betreibt, in der weder gefertigt noch ein formalisierter technischer Außen- oder Reparaturservice abgewickelt wird, fährt mit Essentials in der Regel exakt richtig und sollte nicht vorschnell zur teureren Edition greifen.

Premium: zusätzlich Fertigung und Servicemanagement

Die Edition Premium enthält den vollständigen Funktionsumfang von Essentials und erweitert ihn um genau zwei große, aber gewichtige Funktionsblöcke: Fertigung (Manufacturing) und Servicemanagement (Service Management). Damit adressiert Premium gezielt produzierende Unternehmen und Organisationen mit einem strukturierten technischen Service.

Der Fertigungsteil umfasst Stücklisten und Arbeitspläne, Produktionsaufträge, Kapazitäts- und Maschinenplanung, Bedarfsplanung sowie die Grundlagen einer mehrstufigen Materialwirtschaft – also jene Funktionen, ohne die sich eine Produktion nicht sauber im System abbilden lässt. Das Servicemanagement liefert die Verwaltung von Serviceaufträgen, Serviceartikeln und Serviceverträgen, die Einsatzplanung von Technikern sowie die Abwicklung von Reparatur- und Wartungsprozessen. Beide Blöcke setzen auf den kaufmännischen Kernfunktionen auf, die bereits in Essentials enthalten sind, und verzahnen sich eng mit Lager, Einkauf und Finanzbuchhaltung.

Der typische Premium-Nutzer ist damit ein Vollnutzer in einem Betrieb, der entweder fertigt oder einen formalisierten Service betreibt – etwa ein Fertigungsplaner, ein Werkstattleiter, ein Servicedisponent oder ein Techniker mit Schreibzugriff auf Serviceaufträge. Entscheidend ist eine architektonische Eigenheit der Lizenzierung: Innerhalb desselben Mandanten können Essentials- und Premium-Vollnutzer nicht beliebig gemischt werden. Microsoft verlangt, dass alle Vollnutzer eines Mandanten auf demselben Niveau lizenziert sind. Sobald also auch nur ein Anwender die Fertigungs- oder Servicefunktionen benötigt, müssen sämtliche Vollnutzer dieses Mandanten auf Premium gehoben werden. Diese Regel ist einer der wichtigsten und am häufigsten übersehenen Hebel der gesamten Lizenzkostenplanung.

Team Member: lesender und eng begrenzter Zugriff

Die Lizenz Team Member ist kategorisch anders gelagert als Essentials und Premium. Sie ist keine fachlich reduzierte Vollnutzer-Variante, sondern eine ausdrücklich eingeschränkte Zugriffslizenz für Mitarbeiter, die das System überwiegend lesend nutzen und nur an wenigen, klar umrissenen Stellen schreibend tätig werden. Ein Team Member darf grundsätzlich auf alle Daten des Systems lesend zugreifen, Berichte und Auswertungen aufrufen und in einem eng definierten Rahmen leichte Eingaben vornehmen.

Zu diesen erlaubten Schreibaktionen gehören typischerweise die eigene Zeit- und Spesenerfassung, das Genehmigen von Workflows wie Bestellanforderungen, das Bearbeiten eigener Stammdaten in begrenztem Umfang sowie das Anlegen oder Ändern von Datensätzen in einer kleinen Zahl von Tabellen. Was ein Team Member ausdrücklich nicht darf, ist das Anlegen oder Buchen von Verkaufs-, Einkaufs- oder Fertigungsbelegen oder das eigenständige Führen kaufmännischer Kernprozesse. Sobald ein Mitarbeiter solche Belege erstellen muss, ist zwingend eine Vollnutzer-Lizenz erforderlich.

Die Team-Member-Lizenz richtet sich damit an einen klar abgrenzbaren Kreis: Führungskräfte, die vor allem Kennzahlen und Auswertungen einsehen; Mitarbeiter, die Zeiten und Spesen erfassen; Personen, die Freigaben erteilen; oder Gelegenheitsnutzer, die punktuell Informationen aus dem System ziehen. Für diese Rollen wäre eine Vollnutzer-Lizenz funktional überdimensioniert und unnötig teuer. Richtig eingesetzt ist Team Member daher der zentrale Hebel, um die Gesamtkosten einer ERP-Lösung realistisch zu halten, ohne Mitarbeitern den notwendigen Einblick zu verwehren.

Die in der Tabelle genannten Preise sind ausdrücklich nur Größenordnungen zur Orientierung und kein verbindliches Angebot. Microsoft hat die Listenpreise für die Business-Central-Editionen zum 1. November 2025 angepasst, sodass die maßgeblichen Werte regional und je nach Vertragsweg variieren. Verbindlich sind stets die aktuellen Konditionen aus der offiziellen Microsoft-Preisliste beziehungsweise das Angebot Ihres Lizenzpartners zum Zeitpunkt des Vertragsabschlusses. Die hier genannten Beträge dienen ausschließlich dazu, die Relation zwischen den drei Editionen zu verdeutlichen – und diese Relation ist die eigentlich planungsrelevante Größe: Premium liegt spürbar über Essentials, während Team Member nur einen Bruchteil eines Vollnutzers kostet.

Welche Edition zu welchem Unternehmensprofil passt

Aus der Funktionsabgrenzung lassen sich klare Empfehlungen je Unternehmenstyp ableiten. Sie ersetzen keine individuelle Prüfung, geben aber eine belastbare erste Orientierung.

• Reine Handelsunternehmen und Distributoren: Hier genügt fast immer Essentials, weil Einkauf, Lager, Verkauf und Finanzen vollständig abgedeckt sind. Eine Fertigung existiert nicht, ein technischer Service meist ebenfalls nicht – Premium wäre verschenktes Geld.
• Dienstleistungs- und Projektorganisationen: Auch projektgetriebene Häuser wie Agenturen, Beratungen oder IT-Dienstleister fahren in der Regel mit Essentials, da das integrierte Projektmodul für Buchung, Ressourcen und Zeiterfassung enthalten ist.
• Produzierende Betriebe: Sobald gefertigt wird – mit Stücklisten, Arbeitsplänen und Produktionsaufträgen –, führt an Premium kein Weg vorbei. Das gilt auch für Mischbetriebe, die neben dem Handel eine eigene Fertigung unterhalten.
• Service- und wartungsintensive Unternehmen: Anbieter mit formalisiertem technischem Service, Wartungsverträgen und Technikereinsatzplanung benötigen das in Premium enthaltene Servicemanagement.

Für den breiten Mittelstand ergibt sich daraus eine pragmatische Faustregel: Wer weder fertigt noch einen strukturierten Service betreibt, plant mit Essentials und reizt dessen Funktionsumfang konsequent aus; wer eines von beidem benötigt, kalkuliert von vornherein mit Premium für alle Vollnutzer und prüft, ob die zusätzlichen Funktionen den höheren Preis im gesamten Mandanten rechtfertigen.

Mischlizenzierung: Vollnutzer und Team Member kombinieren

Der eigentliche Hebel zur kosteneffizienten Lizenzierung liegt nicht in der Wahl zwischen Essentials und Premium, sondern in der durchdachten Kombination von Vollnutzern und Team Members. Die zentrale Regel lautet: Innerhalb eines Mandanten müssen alle Vollnutzer auf demselben Niveau – also entweder alle Essentials oder alle Premium – lizenziert sein. Team Members hingegen lassen sich frei und in beliebiger Zahl hinzufügen, unabhängig davon, ob der Mandant auf Essentials oder Premium läuft.

In der Praxis bedeutet das: Man bestimmt zunächst, ob der Betrieb überhaupt Fertigung oder Servicemanagement benötigt, und legt damit das Niveau aller Vollnutzer fest. Anschließend ordnet man jeder Person die kleinstmögliche passende Lizenz zu. Mitarbeiter, die kaufmännische Belege anlegen oder buchen, erhalten eine Vollnutzer-Lizenz; alle, die nur einsehen, freigeben oder Zeiten erfassen, erhalten Team Member. So entsteht typischerweise ein Kern aus relativ wenigen Vollnutzern, ergänzt um eine deutlich größere Zahl günstiger Team-Member-Lizenzen.

Eine wichtige Grenze der Mischlizenzierung ist die Mandantenstruktur: Wer sehr unterschiedliche Geschäftsbereiche betreibt – etwa eine reine Handelssparte und eine separate Fertigung –, kann unter Umständen mit getrennten Mandanten arbeiten, um nicht den gesamten Bestand auf Premium heben zu müssen. Solche Konstruktionen sind jedoch organisatorisch und buchhalterisch anspruchsvoll und sollten nicht allein aus Lizenzgründen gewählt werden. Ob eine Mehrmandantenstruktur sinnvoll ist, hängt von Faktoren ab, die weit über die Lizenzfrage hinausreichen und in einer fundierten Beratung zu klären sind.

Die Editionen als Entscheidungsmatrix lesen

Fasst man die drei Editionen als Matrix zusammen, ergeben sich zwei voneinander unabhängige Achsen. Die erste Achse beschreibt die funktionale Tiefe und verläuft zwischen Essentials und Premium – sie wird durch eine einzige Frage entschieden: Wird gefertigt oder ein formalisierter Service betrieben? Die zweite Achse beschreibt die Zugriffsintensität und verläuft zwischen Vollnutzer und Team Member – sie wird durch die Frage entschieden, ob ein Anwender kaufmännische Belege schreibend führt oder das System überwiegend lesend nutzt.

Diese Zweiachsigkeit erklärt, warum die Lizenzwahl in der Praxis selten eine reine Preisfrage ist. Die funktionale Achse betrifft alle Vollnutzer eines Mandanten gemeinsam und ist daher eine strukturelle Grundsatzentscheidung; die Zugriffsachse betrifft jede Person einzeln und ist der Hebel für die laufende Feinjustierung. Wer beide Achsen sauber trennt, vermeidet die beiden typischen Fehler: die pauschale Premium-Lizenzierung eines reinen Handelsbetriebs einerseits und die teure Vollnutzer-Lizenzierung von Mitarbeitern, die in Wahrheit nur lesen, andererseits.

Für die konkrete Umsetzung empfiehlt es sich, vor jeder Lizenzbestellung eine vollständige Rollenliste des Unternehmens entlang dieser beiden Achsen zu kartieren: Welcher Funktionsumfang ist betrieblich überhaupt erforderlich, und welche Person greift in welcher Intensität auf das System zu? Erst auf dieser Grundlage lässt sich der tatsächliche Lizenzbedarf bestimmen – und genau diese rollenbasierte Kartierung bildet die Brücke zwischen der hier dargestellten Editionsmatrix und der praktischen Einführung von Business Central als tragfähiger ERP-System-Plattform für den eigenen Betrieb.

Cloud (SaaS), On-Premises oder Private Cloud: die Betriebsmodelle gegenübergestellt

Mit Business Central trifft jedes Unternehmen früher oder später eine Grundsatzentscheidung, die weit über die reine Technik hinausreicht: Auf welcher Infrastruktur soll das System laufen, und wer trägt die Verantwortung für Betrieb, Datenhaltung und Weiterentwicklung? Microsoft bietet das Produkt in drei klar unterscheidbaren Betriebsvarianten an. Die Online-Variante ist ein echter Software-as-a-Service-Dienst, der vollständig in Microsoft-Rechenzentren läuft und von Microsoft betrieben wird. Die On-Premises-Variante wird auf eigener oder vom Partner bereitgestellter Hardware installiert und liegt in der vollen Hoheit des Unternehmens beziehungsweise seines Dienstleisters. Dazwischen steht das gehostete oder Private-Cloud-Modell, bei dem dieselbe On-Premises-Codebasis bei einem Hosting-Partner oder in einer dedizierten Azure-Umgebung betrieben wird – technisch On-Premises, im Bezugserlebnis aber cloudähnlich.

Dass die laufenden Cloud-Updates ein gewichtiges Argument für die Online-Variante sind, ist an anderer Stelle bereits ausgeführt. Dieser Abschnitt geht bewusst darüber hinaus und arbeitet die übrigen Unterscheidungsdimensionen heraus: Wer bestimmt über den Zeitpunkt von Aktualisierungen, wo liegen die Daten physisch, wie tief lässt sich das System anpassen, wer haftet für Backup und Ausfallsicherheit, und wie verschieden sind die Kostenmodelle aufgebaut? Diese Fragen entscheiden in der Praxis darüber, welche Variante zu einem Unternehmen passt – und sie sind ein zentraler Baustein jeder fundierten ERP-Auswahl.

Update-Hoheit: Wer entscheidet über den Zeitpunkt?

Der grundlegendste Unterschied zwischen den Varianten betrifft die Frage, wer über das Einspielen von Neuerungen bestimmt. In der Online-Variante liegt diese Hoheit bei Microsoft. Die halbjährlichen Release Waves und die laufenden Service-Updates werden weitgehend automatisch eingespielt; das Unternehmen kann Update-Fenster innerhalb gewisser Grenzen verschieben und in einer Sandbox vorab testen, dem Update selbst aber nicht dauerhaft entgehen. Das nimmt Arbeit ab, bedeutet aber auch, dass die Kompatibilität der eigenen Erweiterungen kontinuierlich sichergestellt sein muss. Genau hier zahlt sich das moderne Erweiterungskonzept aus, dessen Grundlagen der Abschnitt zum Wechsel von C/AL zu AL-Extensions behandelt.

In der On-Premises-Variante liegt die Update-Hoheit vollständig beim Unternehmen. Eine einmal installierte Version kann über Jahre unverändert in Betrieb bleiben; ein Versionssprung ist ein bewusst geplantes Projekt mit eigenem Budget und Zeitplan. Das gibt maximale Kontrolle – etwa, um Aktualisierungen mit firmeneigenen Release-Zyklen oder regulatorischen Stichtagen zu synchronisieren –, verlagert aber die gesamte Verantwortung für den Lebenszyklus auf das Unternehmen. Wer hier zu lange wartet, läuft Gefahr, aus dem unterstützten Wartungsstand zu fallen. Das Private-Cloud-Modell erbt diese Update-Hoheit grundsätzlich von der On-Premises-Welt: Auch hier entscheidet das Unternehmen über den Versionssprung, kann die operative Durchführung aber an den Hosting-Partner delegieren, der die Aktualisierung als Dienstleistung übernimmt.

Datenhaltung und Lokalisierung: Wo liegen die Daten?

Eng mit der Betriebsfrage verbunden ist die Datenhaltung. In der Online-Variante liegen die Produktivdaten in Microsoft-Rechenzentren. Microsoft bietet die Wahl von Regionen und Datenstandorten an, sodass für europäische Kunden eine Datenhaltung innerhalb der EU möglich ist; die konkrete Region wird beim Anlegen der Umgebung festgelegt. Die physische Kontrolle über die Speicherorte gibt das Unternehmen damit jedoch aus der Hand und bewegt sich im Rahmen der Zusicherungen und Zertifizierungen des Anbieters. Für Organisationen mit strengen Vorgaben zur Datenresidenz oder mit vertraglichen Bindungen, die eine Datenhaltung ausschließlich im eigenen Rechtsraum verlangen, ist das ein zentraler Prüfpunkt.

In der On-Premises-Variante liegen die Daten dort, wo das Unternehmen sie hinlegt – im eigenen Serverraum, im firmeneigenen Rechenzentrum oder beim ausdrücklich gewählten Dienstleister. Die volle physische und organisatorische Kontrolle über die Daten ist für manche Branchen, etwa im öffentlichen Sektor oder in stark regulierten Umgebungen, ein gewichtiges Argument. Das Private-Cloud-Modell erlaubt einen Mittelweg: Die Daten liegen in einer dedizierten Umgebung bei einem benannten Hosting-Partner, dessen Standort und vertragliche Rahmenbedingungen das Unternehmen gezielt auswählen kann. Damit lassen sich Anforderungen an die Datenresidenz oft präziser erfüllen als in der standardisierten Online-Variante, ohne dass eigene Hardware betrieben werden muss.

Anpassungstiefe: Wie weit reicht der Eingriff ins System?

Auch beim Spielraum für Anpassungen unterscheiden sich die Varianten deutlich. Die Online-Variante ist bewusst standardisiert: Anpassungen sind ausschließlich über entkoppelte AL-Extensions möglich, die auf den unveränderten Standardkern aufsetzen. Direkte Eingriffe in den Basiscode sind ausgeschlossen – genau das ist die Voraussetzung dafür, dass Microsoft die Software updatefest halten und zentral betreiben kann. Für Unternehmen mit standardnahen Prozessen ist diese Disziplin ein Vorteil, weil sie technische Schulden vermeidet. Für Organisationen mit sehr speziellen, tief in die Logik eingreifenden Anforderungen kann sie eine spürbare Grenze sein.

Die On-Premises-Variante bietet hier den größten Spielraum. Neben Extensions sind im Prinzip tiefere Eingriffe, eigene Integrationen auf Systemebene und der Betrieb zusätzlicher, eng verzahnter Dienste auf demselben Server möglich. Diese Freiheit hat ihren Preis: Jeder Eingriff jenseits des Standards muss bei künftigen Upgrades berücksichtigt werden und erhöht den Wartungsaufwand. Das Private-Cloud-Modell teilt diesen Spielraum, weil es technisch auf der On-Premises-Codebasis beruht. Es eignet sich daher für Unternehmen, die eine über die Online-Grenzen hinausgehende Anpassungstiefe benötigen, den Betrieb der Infrastruktur aber dennoch nicht selbst übernehmen wollen. Welche Variante zu den eigenen Prozessen passt, lässt sich seriös nur im Rahmen eines strukturierten Vorgehens klären, wie es das ERP-Consulting begleitet.

Backup- und Ausfallverantwortung: Wer haftet, wenn etwas ausfällt?

Die Frage, wer für Datensicherung und Verfügbarkeit geradesteht, wird in der Praxis oft unterschätzt, ist aber im Ernstfall entscheidend. In der Online-Variante übernimmt Microsoft Backup, Wiederherstellung und Ausfallsicherheit als Bestandteil des Dienstes. Sicherungen erfolgen automatisch im Hintergrund, die Verfügbarkeit wird vertraglich zugesichert, und die Redundanz der Rechenzentren liegt jenseits dessen, was ein einzelner Mittelständler wirtschaftlich selbst aufbauen könnte. Das Unternehmen gibt dafür ein Stück operativer Eingriffsmöglichkeit ab: Eine Wiederherstellung auf einen sehr spezifischen Zeitpunkt richtet sich nach den Vorgaben des Dienstes, nicht nach einem frei definierten eigenen Sicherungskonzept.

In der On-Premises-Variante liegt die gesamte Verantwortung beim Unternehmen. Backup-Strategie, Aufbewahrungsfristen, Wiederanlaufzeiten und Redundanz müssen selbst geplant, umgesetzt und – das ist der häufig vergessene Teil – regelmäßig getestet werden. Das erlaubt maßgeschneiderte Sicherungskonzepte, setzt aber entsprechende Kompetenz und Disziplin voraus. Fällt ein Server aus, ist es Sache des Unternehmens oder seines Partners, den Betrieb wiederherzustellen. Im Private-Cloud-Modell wird diese Verantwortung in der Regel vertraglich auf den Hosting-Partner übertragen, der Backup und Verfügbarkeit als Teil seines Service-Level-Agreements zusichert. Damit entsteht ein Modell, das die Entlastung der Cloud mit individuell verhandelbaren Konditionen verbindet – allerdings nur so verlässlich, wie das zugrunde liegende SLA und der gewählte Partner es hergeben.

Kostenstruktur: Subscription gegen Lizenzkauf plus Enhancement Plan

Die Betriebsmodelle unterscheiden sich nicht nur technisch, sondern grundlegend in der Logik der Kosten. Die Online-Variante folgt dem Subscription-Prinzip: Es wird ein laufendes, in der Regel monatliches Entgelt je Nutzer entrichtet, das Betrieb, Wartung, Updates, Backup und Infrastruktur bündelt. Es gibt keine große Anfangsinvestition in Lizenzen oder Hardware; die Kosten sind als planbare Betriebsausgabe strukturiert und skalieren mit der Zahl der tatsächlich benötigten Nutzer. Das senkt die Einstiegshürde erheblich und macht das Modell für den Mittelstand ohne große eigene IT-Mannschaft besonders attraktiv.

Die On-Premises-Variante folgt der klassischen Logik des Lizenzkaufs zuzüglich eines laufenden Enhancement Plans. Die Lizenzen werden einmalig erworben und gehören dem Unternehmen; der Enhancement Plan ist eine jährliche Wartungsgebühr, die den Zugang zu neuen Versionen und Support sichert. Hinzu kommen die Kosten für Hardware, Betrieb, Strom, Administration und Sicherung, die nicht im Lizenzpreis enthalten sind. Diese Variante verlagert das Gewicht von laufenden Entgelten auf eine Anfangsinvestition und macht die Gesamtkosten über die Jahre stark vom eigenen Betriebsaufwand abhängig. Das Private-Cloud-Modell kombiniert beide Welten: Es kann auf einer gekauften On-Premises-Lizenz mit Enhancement Plan beruhen, ergänzt diese aber um ein laufendes Hosting-Entgelt für Betrieb und Infrastruktur beim Partner. Damit entstehen Mischkalkulationen, die im Einzelfall sorgfältig durchzurechnen sind.

Skalierung und strategische Priorisierung durch Microsoft

Beim Thema Skalierung spielt die Online-Variante ihre Stärke aus: Nutzer lassen sich kurzfristig hinzubuchen oder abbestellen, ohne dass Hardware beschafft oder abgebaut werden muss. Die zugrunde liegende Infrastruktur ist elastisch und wird vom Anbieter bereitgestellt. In der On-Premises-Variante ist Skalierung dagegen an die eigene Hardware gebunden: Wachstum muss vorausschauend dimensioniert werden, und Lastspitzen lassen sich nicht ohne Weiteres elastisch abfangen. Das Private-Cloud-Modell liegt auch hier dazwischen – die Skalierung hängt vom Vertrag mit dem Hosting-Partner ab und ist flexibler als eigene Hardware, aber selten so unmittelbar elastisch wie der reine SaaS-Dienst.

Bei aller Gleichwertigkeit der Optionen ist ein strategischer Punkt nicht zu übersehen: Microsoft priorisiert die SaaS-Variante deutlich. Die Online-Variante ist die Plattform, auf der neue Funktionen zuerst erscheinen und auf die die Weiterentwicklung des Produkts ausgerichtet ist. Bestimmte Neuerungen – insbesondere die enge Verzahnung mit der Power Platform, Copilot-gestützte Funktionen und Teile der tieferen Microsoft-365-Integration – sind in der Online-Variante früher oder ausschließlich verfügbar. Welche Möglichkeiten dieses Ökosystem eröffnet, behandelt der eigene Abschnitt zur Einbettung von Business Central in Power Platform, Microsoft 365 und Azure. Für die Betriebsmodell-Entscheidung ist hier nur festzuhalten: Wer On-Premises oder im Private-Cloud-Modell bleibt, sichert sich Kontrolle und Anpassungstiefe, akzeptiert aber tendenziell einen zeitlichen Versatz beim Zugang zu den neuesten, cloudgebundenen Innovationen.

Entscheidungslogik in der Praxis: Die Wahl des Betriebsmodells ist keine reine IT-Frage, sondern ein Abwägen zwischen Kontrolle und Entlastung. Wer standardnahe Prozesse, eine schlanke IT und planbare Betriebskosten will, fährt mit der Online-Variante regelmäßig am besten. Wer maximale Anpassungstiefe, volle Datenhoheit oder regulatorische Sonderanforderungen hat, findet in On-Premises oder im Private-Cloud-Modell die passende Antwort. Die Entscheidung sollte nicht isoliert getroffen, sondern als integraler Teil der ERP-Lösungsstrategie mit Versionsstand, Anpassungstiefe und Zielbild gemeinsam betrachtet werden.

Unterm Strich bilden die drei Varianten ein Spektrum: Auf der einen Seite die vollständig von Microsoft betriebene, standardisierte und kontinuierlich aktualisierte SaaS-Cloud; auf der anderen Seite die selbst verantwortete, maximal anpassbare On-Premises-Installation; und dazwischen das Private-Cloud-Modell als Brücke, das On-Premises-Freiheiten mit ausgelagertem Betrieb verbindet. Keine Variante ist per se überlegen – entscheidend ist, welche Gewichtung zwischen Update-Hoheit, Datenstandort, Anpassbarkeit, Ausfallverantwortung, Kosten und Skalierbarkeit zur konkreten Situation eines Unternehmens passt. Die ehrliche Auseinandersetzung mit diesen Dimensionen ist der Kern jeder tragfähigen Betriebsmodell-Entscheidung rund um Business Central.

Von C/AL zu AL-Extensions: warum Alt-Anpassungen den Umstieg prägen

Kaum eine Navision-Installation, die über Jahre gewachsen ist, läuft im reinen Auslieferungszustand. In der langen Ära von C/SIDE und der Programmiersprache C/AL war es gängige und ausdrücklich vorgesehene Praxis, den Standard an die eigenen Abläufe anzupassen, indem man die mitgelieferten Objekte schlicht aufschnitt und veränderte. Genau dieses Code-Erbe wird beim Umstieg auf Microsoft Dynamics 365 Business Central zur entscheidenden Größe – nicht die Anzahl der Lizenzen, nicht die Datenmenge, sondern die Frage, wie tief frühere Anpassungen in den Kern eingegriffen haben. Dieser Abschnitt nimmt deshalb gezielt das Anpassungs- und Code-Erbe in den Blick: den technischen Paradigmenwechsel vom direkten Objekteingriff hin zum entkoppelten Erweiterungsmodell, die Rolle von Per-Tenant-Extensions und AppSource und die Folgen für Updatefähigkeit und Wartungskosten. Die organisatorische Seite eines solchen Vorhabens – Projektphasen, Verantwortlichkeiten, Datenübernahme – behandelt die bereits vorhandene Umstiegs-Checkliste; hier geht es ausschließlich um die technische Substanz dahinter.

Das alte Modell: C/AL und der direkte Eingriff in den Standard

Um zu verstehen, warum ein Umstieg so unterschiedlich aufwendig ausfallen kann, muss man sich vergegenwärtigen, wie Anpassungen in der C/AL-Welt funktioniert haben. C/AL (Client/server Application Language) war die Programmiersprache der Entwicklungsumgebung C/SIDE, die Navision von den frühen Versionen bis in die NAV-Generation hinein begleitet hat. In dieser Architektur gab es keine Trennung zwischen Standardcode und Kundenanpassung. Alle Funktionalität – ob von Microsoft ausgeliefert oder vom Partner ergänzt – lag in denselben Objekten: Tabellen, Pages (früher Formularen), Reports, Codeunits und XMLports. Wer eine zusätzliche Prüfung in der Buchungsroutine brauchte, öffnete die betreffende Codeunit und schrieb seine Zeilen direkt in den Standardablauf hinein. Wer ein Feld auf einer Beleg-Tabelle benötigte, fügte es unmittelbar der ausgelieferten Tabelle hinzu.

Dieses Vorgehen war bestechend pragmatisch und ein wesentlicher Grund für die enorme Verbreitung von Navision im Mittelstand: Das System ließ sich nahezu beliebig formen, und ein erfahrener Partner konnte Sonderwünsche unmittelbar im Quellcode abbilden. Der Preis dafür zeigte sich erst beim nächsten Versionswechsel. Weil Kundencode und Standardcode untrennbar im selben Objekt lagen, ließ sich ein Update nicht einfach „darüber“ installieren. Stattdessen war ein Code-Merge nötig: Die neue Standardversion und die individuell veränderte Bestandsversion mussten Objekt für Objekt, oft Zeile für Zeile, zusammengeführt werden. Je mehr Standardobjekte über die Jahre angefasst worden waren, desto größer war die Schnittmenge der Konflikte – und desto teurer, langwieriger und fehleranfälliger der Sprung auf die nächste Version. Genau aus diesem Grund blieben viele Installationen über Jahre auf einem einmal erreichten Stand stehen: Das Update war schlicht ein eigenständiges Projekt geworden.

Der Paradigmenwechsel: Anpassung als entkoppelte Erweiterung

Mit dem Übergang zu Business Central hat Microsoft diese Logik grundlegend umgekehrt. An die Stelle von C/AL ist die Sprache AL getreten, und mit ihr ein vollständig anderes Modell, wie Anpassungen entstehen und leben. Der Kerngedanke lautet: Der Standard wird nicht mehr verändert, sondern erweitert. Anpassungen liegen nicht länger als Bearbeitung der ausgelieferten Objekte vor, sondern als eigenständige, abgegrenzte Pakete – die AL-Extensions. Eine Extension ist eine eigene Einheit (technisch ausgeliefert als App-Paket), die sich an den unveränderten Standard andockt, ohne ihn anzufassen.

Möglich wird das durch ein Set von Konzepten, die es in der C/AL-Welt so nicht gab. Statt ein Feld direkt in die Standardtabelle zu schreiben, definiert eine Extension eine Table Extension, die der Standardtabelle Felder hinzufügt, ohne deren Definition zu berühren. Statt eine Standard-Page aufzuschneiden, ergänzt eine Page Extension zusätzliche Felder oder Aktionen an definierten Stellen. Und statt Code mitten in eine Standard-Codeunit zu schreiben, abonniert eine Extension über Events klar benannte Auslösepunkte im Standardablauf: Microsoft veröffentlicht im Code Ereignisse („publisher“), und die Erweiterung hängt sich mit ihrem eigenen Code als „subscriber“ daran. Der Standard ruft das Ereignis auf; die Erweiterung reagiert – ohne dass je eine Zeile Standardcode geändert wurde. Aus dem direkten Eingriff ist damit ein kontraktbasiertes Andocken an definierte Schnittstellen geworden.

Der entscheidende Effekt dieser Entkopplung betrifft das Update. Weil der Standardkern bei jeder Anpassung unberührt bleibt, kann Microsoft eine neue Version der Base Application einspielen, ohne dass dabei Kundencode überschrieben oder zusammengeführt werden müsste. Die Erweiterungen sitzen als separate Schicht darüber; sie werden gegen die neue Standardversion lediglich neu kompiliert und auf Kompatibilität geprüft. Aus dem mühsamen Code-Merge der C/AL-Ära ist damit im Idealfall ein kontrollierter Rekompilierungs- und Testdurchlauf geworden. Genau diese Eigenschaft ist die technische Grundlage für die laufenden Cloud-Updates, deren Auswirkungen auf die Update-Hoheit an anderer Stelle dieser Seite vertieft werden.

Zwei Wege für Erweiterungen: AppSource und Per-Tenant-Extensions

AL-Extensions treten in der Praxis in zwei klar unterschiedenen Ausprägungen auf, die unterschiedliche Zwecke erfüllen und sich – das ist wichtig für das Verständnis des Modells – problemlos kombinieren lassen.

Die AppSource-Apps sind Erweiterungen, die über den öffentlichen Microsoft-Marktplatz AppSource vertrieben werden. Sie sind so konzipiert, dass sie bei vielen Kunden gleichzeitig laufen können: eine Branchenlösung, eine Schnittstelle zu einem Zahlungsdienstleister, ein erweitertes Dokumentenmanagement. Solche Apps durchlaufen einen technischen Validierungsprozess von Microsoft, werden vom jeweiligen Anbieter gepflegt und gegen neue Releases aktualisiert. Für das Unternehmen bedeutet das: Funktionalität, die früher als individuelle C/AL-Anpassung programmiert worden wäre, lässt sich heute oft als fertige, vom Anbieter gewartete App beziehen – und die Verantwortung für die Update-Kompatibilität liegt dann beim Anbieter, nicht beim eigenen Betrieb.

Die Per-Tenant-Extensions (PTE) dagegen sind individuell für genau eine Installation – einen Mandanten – entwickelt. Sie bilden die echten Sonderprozesse eines Unternehmens ab, die sich nicht aus dem Markt beziehen lassen, weil sie spezifisch sind. Eine PTE wird nicht über AppSource veröffentlicht, sondern direkt in die Umgebung des Unternehmens eingespielt. Sie ist gewissermaßen der legitime Nachfolger der alten Individualanpassung – mit dem fundamentalen Unterschied, dass sie den Standard nicht mehr verändert, sondern als saubere, abgegrenzte Schicht daneben liegt. In der Mehrzahl realer Business-Central-Projekte entsteht so ein Stapel: der Microsoft-Standard als Basis, darüber eine oder mehrere AppSource-Apps für zugekaufte Funktionalität und obenauf eine Per-Tenant-Extension für das, was wirklich unternehmensindividuell ist.

Warum stark individualisierte Installationen aufwendiger umziehen

Aus dem Paradigmenwechsel folgt unmittelbar, warum der Umstieg so ungleich schwer ausfällt. Eine NAV-Installation, die nah am Standard betrieben wurde und nur wenige, gut abgegrenzte Anpassungen besitzt, lässt sich vergleichsweise geradlinig in das Extension-Modell überführen: Die wenigen Sonderfunktionen werden als Per-Tenant-Extension neu konzipiert, der Rest deckt sich mit dem Standard. Eine über viele Jahre tief individualisierte Installation dagegen stellt eine ganz andere Aufgabe. Dort ist Kundenlogik über zahlreiche Standardobjekte verteilt und mit dem ausgelieferten Code verwoben. Diese Logik lässt sich nicht „mitnehmen“ – sie muss analysiert, von der Standardfunktionalität getrennt und im Extension-Modell neu gedacht werden.

Drei Punkte verschärfen diesen Aufwand. Erstens ist der Übergang von C/AL zu AL kein reines Umformatieren, sondern eine konzeptionelle Übersetzung: Ein direkter Eingriff in eine Standard-Codeunit muss zu einem Ereignis-Abonnement werden, und das setzt voraus, dass an der benötigten Stelle überhaupt ein passendes Ereignis existiert oder eine andere Erweiterungsstrategie gefunden wird. Zweitens deckt eine solche Analyse regelmäßig Altlasten auf – Anpassungen, deren ursprünglicher Zweck niemand mehr kennt, oder Funktionen, die inzwischen vom Standard abgedeckt werden und schlicht entfallen können. Drittens trifft die Migration in der Cloud-Variante auf die harte Grenze, dass dort nur das Extension-Modell zulässig ist: Was sich nicht sauber als Erweiterung abbilden lässt, kann dort gar nicht erst betrieben werden. Eine ehrliche Bestandsaufnahme der vorhandenen Anpassungstiefe ist deshalb der erste Schritt jeder belastbaren Migrationsplanung – und ein klassischer Gegenstand von ERP-Consulting, das den vorhandenen Code bewertet, bevor ein Zeit- und Budgetrahmen überhaupt seriös benannt werden kann.

Folgen für Updatefähigkeit und Wartungskosten

Der eigentliche Lohn des Schnitts zeigt sich nach dem Umstieg, im laufenden Betrieb. Solange Anpassungen sauber als Extensions vom Standard getrennt sind, bleibt die Installation updatefähig. Neue Releases können eingespielt werden, ohne dass jedes Mal ein riskanter Code-Merge ansteht; im günstigen Fall genügt es, die eigenen Erweiterungen gegen die neue Version zu kompilieren und zu testen. Damit entfällt der wesentliche Grund, aus dem Navision-Installationen früher technologisch eingefroren sind. Die Software bleibt auf einem aktuellen, von Microsoft unterstützten Stand, und das Unternehmen profitiert kontinuierlich von Sicherheits-, Funktions- und Plattformverbesserungen.

Auch die Struktur der Wartungskosten verschiebt sich. Im C/AL-Modell konzentrierte sich der Aufwand in selteneren, dafür großen und schwer kalkulierbaren Upgrade-Projekten. Im Extension-Modell verteilt er sich auf kontinuierliche, kleinere und besser planbare Anpassungs- und Testzyklen, die mit dem Release-Rhythmus mitlaufen. Hinzu kommt eine veränderte Verantwortungsteilung: Was als AppSource-App bezogen wird, pflegt der jeweilige Anbieter; nur die echten Per-Tenant-Eigenentwicklungen verbleiben in der Obhut des Unternehmens und seines Partners. Das reduziert die Fläche, für die das Unternehmen die Update-Kompatibilität selbst sicherstellen muss – allerdings nur, wenn die Eigenentwicklungen diszipliniert klein und klar abgegrenzt gehalten werden.

Diese Disziplin ist die Kehrseite des Versprechens. Die Updatefähigkeit ist kein automatischer Zustand, sondern das Ergebnis konsequenter Bauweise. Eine Extension, die mit fragwürdigen Mitteln doch wieder in den Standard hineinregiert oder sich an instabile interne Strukturen klammert, kann beim nächsten Release brechen – und verlagert das alte Merge-Problem nur auf eine neue Ebene. Der Gewinn an Wartbarkeit hängt also unmittelbar an der Qualität der Erweiterungen und damit an der Kompetenz des umsetzenden Partners. Eine saubere Migration ist deshalb weit mehr als ein technischer Transport: Sie ist eine bewusste Neuordnung des gewachsenen Code-Erbes, deren Sorgfalt über Jahre hinweg in niedrigeren Update-Risiken und planbareren Betriebskosten zurückgezahlt wird – ein Aspekt, der bei einer fundierten ERP-Auswahl rund um Business Central von Anfang an mitgedacht gehört.

Unterm Strich ist der Weg von C/AL zu AL-Extensions kein bloßer Sprachwechsel, sondern die Ablösung eines ganzen Anpassungsparadigmas. Das alte Modell stellte maximale Formbarkeit über die Updatefähigkeit; das neue stellt die Updatefähigkeit an die Spitze und kanalisiert jede Anpassung in eine entkoppelte Schicht. Genau dieser Schnitt entscheidet, wie aufwendig ein Umstieg wird, denn er zwingt dazu, das über Jahre gewachsene Code-Erbe nicht zu kopieren, sondern bewusst zu übersetzen. Wer diese Übersetzung ernst nimmt, gewinnt ein System, das sich – anders als die eingefrorenen Navision-Installationen der Vergangenheit – dauerhaft mit dem Standard fortbewegt.

Business Central im Microsoft-Ökosystem: Power Platform, Microsoft 365 und Azure

Wer Business Central einführt, kauft nicht nur ein betriebswirtschaftliches Kernsystem, sondern dockt zugleich an eine der größten zusammenhängenden Software-Plattformen der Welt an. Das ist der eigentliche strategische Unterschied dieses Produkts gegenüber Wettbewerbern: Business Central ist nicht als Insel konzipiert, sondern als ein Baustein in einem Verbund aus Produktivitätswerkzeugen, Auswertungs- und Automatisierungsdiensten sowie einer durchgängigen Betriebs- und Datenplattform. Für ein Unternehmen, das ohnehin Outlook, Excel, Teams und SharePoint nutzt und seine Daten in Microsoft-Diensten verwaltet, verschiebt sich damit die Auswahlfrage. Es geht nicht mehr nur darum, welches ERP-System die beste Funktionsabdeckung bietet, sondern auch darum, welches sich nahtlos in die bereits vorhandene digitale Arbeitsumgebung einfügt.

Dieser Abschnitt beleuchtet ausschließlich diese Einbettung in das Microsoft-Ökosystem – also die Architektur des Zusammenspiels zwischen Business Central, Microsoft 365, der Power Platform, Azure als Betriebsfundament und dem gemeinsamen Datenmodell Dataverse. Es geht nicht um den betriebswirtschaftlichen Funktionsumfang des Systems und auch nicht um Editionen, Betriebsmodelle oder die Versionslinie, die in eigenen Abschnitten behandelt werden. Im Mittelpunkt steht die Frage, wie tief und auf welchen Wegen Business Central technisch mit den übrigen Microsoft-Diensten verzahnt ist, warum genau diese Verzahnung für bestehende Microsoft-Anwender ein zentrales Argument darstellt – und an welcher Stelle Lizenz- und Komplexitätsfolgen die Begeisterung dämpfen sollten.

Das Bild der Nabe und der Speichen: Business Central als integrierter Mittelpunkt

Um die Integration zu verstehen, hilft ein Architekturbild: Business Central ist die Nabe, in der die transaktionalen Geschäftsdaten – Belege, Buchungen, Stammdaten, Bestände – konsolidiert werden. Von dieser Nabe führen Speichen zu den umgebenden Microsoft-Diensten. Über die Speiche der Produktivität fließen Daten zu Outlook, Excel und Teams, dorthin also, wo Mitarbeitende ohnehin den Großteil ihres Arbeitstages verbringen. Über die Speiche der Analyse und Automatisierung gelangen sie zu Power BI, Power Automate und Power Apps. Und das gesamte Konstrukt ruht auf einer Betriebs- und Datenschicht aus Azure und Dataverse, die die Verbindung technisch trägt. Entscheidend ist, dass diese Flüsse in der Regel bidirektional sind: Daten werden nicht nur aus Business Central herausgereicht, sondern lassen sich aus den umgebenden Diensten auch wieder zurückschreiben.

Der Reiz dieses Modells liegt darin, dass die Speichen nicht über mühsam zu pflegende Punkt-zu-Punkt-Schnittstellen verbunden sind, wie man sie zwischen Produkten unterschiedlicher Hersteller bauen müsste, sondern dass sie demselben Plattformfundament entstammen. Identität, Berechtigungen, Datenmodell und Betrieb sind in weiten Teilen geteilt. Das senkt den Integrationsaufwand erheblich – allerdings nur innerhalb der Microsoft-Welt, was die spätere Diskussion der Grenzen vorzeichnet.

Microsoft 365: Arbeiten dort, wo die Anwender ohnehin sind

Die für den Arbeitsalltag spürbarste Speiche führt zu Microsoft 365. Die Grundidee lautet, betriebswirtschaftliche Vorgänge nicht zwingend in der ERP-Oberfläche, sondern im jeweils vertrauten Produktivitätswerkzeug abwickeln zu können. In Outlook bedeutet das, dass ein eingehender Beleg – etwa eine Bestellung oder Anfrage per E-Mail – über ein eingebettetes Add-in direkt verarbeitet werden kann. Der Anwender sieht im Posteingang Kunden- oder Lieferantenkontext aus Business Central, kann ein Angebot erzeugen oder eine Rechnung erstellen, ohne die Mail-Anwendung zu verlassen. Die Daten werden im Hintergrund in die Nabe geschrieben.

Bei Excel geht die Integration über den simplen Export hinaus. Datensätze lassen sich nicht nur nach Excel exportieren, sondern über die Funktion „In Excel bearbeiten" auch dort verändern und anschließend wieder in das System zurückschreiben. Das ist gerade in Finanz- und Controlling-Prozessen wertvoll, in denen Massenpflege und Tabellenkalkulation seit jeher das natürliche Werkzeug sind. Die vertraute Tabelle wird so zur produktiven Eingabeoberfläche, statt nur eine Sackgasse für ausgelesene Zahlen zu sein. Teams wiederum verschiebt den ERP-Zugriff in den Kontext der Zusammenarbeit: Einzelne Datensätze oder ganze Listen lassen sich in einen Chat oder Kanal einbetten, sodass über einen konkreten Kunden, einen Auftrag oder eine Kennzahl diskutiert werden kann, ohne dass jeder Beteiligte die ERP-Oberfläche öffnen muss. Für Mitarbeitende, die nur gelegentlich lesend auf Geschäftsdaten zugreifen, kann Teams damit faktisch zur primären ERP-Schnittstelle werden.

Der gemeinsame Nenner dieser drei Beispiele ist eine Verlagerung der Interaktion: Das ERP rückt aus dem Zentrum der Aufmerksamkeit in den Hintergrund und stellt seine Daten und Funktionen dort bereit, wo gearbeitet wird. Für die Akzeptanz eines Systems – traditionell eine der größten Hürden jeder ERP-Einführung – ist das ein erheblicher Vorteil, weil es die Schwelle zur Nutzung senkt und Medienbrüche zwischen Kommunikation und Transaktion vermeidet.

Power BI: Auswertungen auf den Live-Daten der Nabe

Die analytische Speiche bildet Power BI. Während Business Central selbst über solide Standardberichte und Kontenschemata verfügt, ist Power BI das Werkzeug für die freie, visuelle und verdichtende Auswertung. Der entscheidende Architekturpunkt ist, dass Power-BI-Berichte direkt auf den Daten der Nabe aufsetzen und sich – das ist der eigentliche Integrationsvorteil – als Kacheln und Dashboards unmittelbar in die Rollencenter von Business Central einbetten lassen. Der Anwender verlässt das System nicht, um seine Kennzahlen zu sehen; die Analyse erscheint an dem Ort, an dem er ohnehin arbeitet.

Damit entsteht eine klare Arbeitsteilung: Die Nabe ist das System of Record für die transaktionale Wahrheit, Power BI ist das System of Insight für die verdichtete Sicht darauf. Dieser Fluss ist im Kern lesend – Power BI verändert die Geschäftsdaten nicht, sondern interpretiert sie. Gerade deshalb eignet sich das Werkzeug, um aus dem operativen Tagesgeschäft heraus strategische Auswertungen zu gewinnen, ohne den produktiven Datenbestand zu gefährden. Für Unternehmen, die ihre Auswertungslandschaft bislang über mühsam gepflegte Tabellen organisiert haben, ist diese eingebettete, stets aktuelle Analyse häufig einer der überzeugendsten Aspekte des Ökosystems.

Power Automate und Power Apps: Workflows und Erweiterungen ohne Kerneingriff

Die zweite und dritte Speiche der Power Platform betreffen Automatisierung und Erweiterung. Power Automate ermöglicht es, Abläufe über Systemgrenzen hinweg zu automatisieren, ohne dafür programmieren zu müssen. Ein typisches Muster ist eine mehrstufige Genehmigung: Überschreitet ein in Business Central erfasster Einkaufsbeleg einen Schwellenwert, löst dies in Power Automate einen Workflow aus, der eine Freigabeanfrage in Teams oder per E-Mail verschickt; die Entscheidung wird anschließend wieder in die Nabe zurückgeschrieben. Dieser Fluss ist also ausdrücklich bidirektional – Power Automate liest Auslöser aus dem ERP und schreibt Ergebnisse dorthin zurück, kann dabei aber im selben Ablauf Dutzende weiterer Dienste einbeziehen.

Power Apps schließlich erlaubt es, maßgeschneiderte Anwendungen auf den Geschäftsdaten zu bauen – etwa eine schlanke mobile App für die Lagererfassung oder ein vereinfachtes Eingabeformular für eine bestimmte Anwendergruppe –, ohne den Standardkern von Business Central anzutasten. Das ist konzeptionell verwandt mit dem Erweiterungsgedanken, der den Umstieg von alten Anpassungen prägt und in einem eigenen Abschnitt zu Navision-Software ausführlich behandelt wird: Erweitert wird neben dem Kern, nicht in ihm. Der gemeinsame Vorteil von Power Automate und Power Apps liegt im sogenannten Low-Code-Ansatz, der es auch versierten Fachanwendern erlaubt, Abläufe und Oberflächen zu gestalten, statt jeden Wunsch an die Entwicklungsabteilung weiterzureichen. Das beschleunigt die Anpassung an betriebliche Eigenheiten erheblich – birgt aber zugleich, wie noch zu zeigen sein wird, das Risiko einer unkontrollierten Wildwucherung von Apps und Automatismen.

Dataverse und Standard-APIs: das technische Bindeglied

Damit Daten zwischen Nabe und Speichen fließen können, braucht es ein verbindendes Datenmodell und definierte Schnittstellen. Diese Rolle übernehmen Dataverse und die Standard-APIs von Business Central. Dataverse ist das gemeinsame, strukturierte Datenmodell der Power Platform; über eine konfigurierbare Synchronisation lassen sich Entitäten wie Kunden, Kontakte oder Artikel zwischen Business Central und Dataverse abgleichen. Das ist die technische Grundlage dafür, dass ein Datensatz, der in einer Power App oder in einem nachgelagerten CRM-Kontext bearbeitet wird, denselben Kunden meint wie der Datensatz im ERP. Ohne ein solches geteiltes Modell bliebe jede Integration eine fehleranfällige Übersetzungsleistung zwischen unterschiedlichen Datenwelten.

Ergänzend stellt Business Central standardisierte REST- und OData-Schnittstellen bereit. Über diese APIs können sowohl die Microsoft-eigenen Dienste als auch Drittsysteme lesend und schreibend auf die Geschäftsdaten zugreifen. Damit öffnet sich die Nabe kontrolliert nach außen, ohne dass für jede Anbindung eine proprietäre Sonderlösung gebaut werden müsste. Dieses Schnittstellenfundament ist der Grund, warum sich Business Central nicht nur in das Microsoft-Ökosystem, sondern grundsätzlich auch in heterogene Systemlandschaften einfügen lässt – ein Punkt, der bei der Bewertung einer ERP-Lösung für gewachsene IT-Umgebungen schwer wiegt.

Azure: das tragende Betriebsfundament

Unter dem gesamten Verbund liegt Azure als Betriebsplattform. In der Cloud-Variante wird Business Central in Microsoft-Rechenzentren auf Azure betrieben; auch die Power Platform und große Teile von Microsoft 365 ruhen auf derselben Infrastruktur. Diese gemeinsame Basis hat mehrere Konsequenzen, die für die Integration entscheidend sind. Erstens teilen sich die Dienste die Identitätsverwaltung über Entra ID (vormals Azure Active Directory): Ein Anwender meldet sich einmal an und greift mit denselben Zugangsdaten und Berechtigungen auf ERP, Office-Anwendungen und Power-Plattform-Dienste zu. Das vereinfacht nicht nur den Alltag, sondern auch die zentrale Steuerung von Sicherheit und Zugriffsrechten erheblich.

Zweitens stellt Azure die Mechanismen für Skalierung, Verfügbarkeit und Sicherheit bereit, auf denen die Verlässlichkeit des gesamten Verbunds beruht. Drittens ist Azure die Ebene, auf der sich der Verbund über die genannten Standard-Speichen hinaus erweitern lässt – etwa durch eigene Dienste, durch die Anbindung von Azure-Datendiensten für umfangreichere Analyseszenarien oder durch KI-gestützte Funktionen, die zunehmend Teil der Plattform werden. Für die Einbettung ist vor allem festzuhalten: Weil ERP, Produktivität und Plattformdienste auf demselben Fundament stehen, sind ihre Verbindungen keine nachträglich aufgesetzten Brücken, sondern Eigenschaften einer gemeinsamen Architektur.

Warum die Integration ein zentrales Auswahlargument ist

Für ein Unternehmen, das bereits in der Microsoft-Welt zu Hause ist, summieren sich diese Speichen zu einem gewichtigen Argument bei der ERP-Auswahl. Der Wert entsteht nicht aus einer einzelnen Funktion, sondern aus dem Zusammenwirken: Die vorhandenen Lizenzen, die vertraute Oberfläche, die bestehende Identitätsverwaltung und die geübten Arbeitsabläufe in Outlook, Excel und Teams müssen nicht ersetzt, sondern werden um eine betriebswirtschaftliche Tiefe erweitert. Das senkt die Einführungshürde, verkürzt Schulungsaufwände und erhöht die Wahrscheinlichkeit, dass ein neues System tatsächlich angenommen wird, statt neben den gewohnten Werkzeugen ein ungeliebtes Eigenleben zu führen.

Hinzu kommt die strategische Verlässlichkeit, mit einer einzigen, durchgängig integrierten Plattform zu arbeiten, statt eine Sammlung lose gekoppelter Einzelprodukte zu orchestrieren. Verantwortung für Betrieb, Sicherheit und Weiterentwicklung liegt gebündelt; Innovationen wie neue Analyse- oder Automatisierungsfunktionen erreichen alle Dienste über dasselbe Fundament. Für viele mittelständische Organisationen, die keine große IT-Mannschaft zur Pflege heterogener Schnittstellenlandschaften unterhalten, ist diese Bündelung ein handfester betrieblicher Vorteil – und genau deshalb ist die Ökosystem-Frage für Microsoft-Anwender oft wichtiger als der letzte Funktionsvergleich auf der Merkmalsliste.

Wo die Grenzen liegen: Lizenz- und Komplexitätsfolgen

So überzeugend die Integration ist, sie hat ihren Preis, und der zeigt sich auf zwei Ebenen. Die erste betrifft Lizenzen und Kosten. Die Speichen sind nicht sämtlich im ERP-Preis enthalten. Power BI, Power Automate und Power Apps sind eigenständige Produkte mit eigener Lizenzlogik; bestimmte Nutzungsumfänge – etwa der Betrieb umfangreicher eigener Apps oder Premium-Konnektoren – erfordern zusätzliche Lizenzstufen. Was als nahtlose Erweiterung erscheint, kann sich in der Summe zu einer mehrschichtigen Lizenzstruktur auswachsen, deren Gesamtkosten nicht beim ERP-Listenpreis enden. Wer das Ökosystem voll ausschöpfen will, muss die Lizenzfolgen über alle beteiligten Dienste hinweg durchrechnen, statt nur die ERP-Edition zu betrachten.

Die zweite Ebene betrifft die Komplexität. Eine Plattform, auf der Fachanwender per Low-Code eigene Apps bauen und eigene Automatismen schalten können, erzeugt ohne Steuerung leicht einen Wildwuchs: verstreute Workflows, deren Logik niemand mehr überblickt, Apps ohne klare Verantwortlichkeit, undokumentierte Datenflüsse zwischen Diensten. Was als Demokratisierung der Entwicklung gedacht ist, kann ohne Governance in eine schwer wartbare Schatten-IT münden. Die Integration verlangt deshalb klare Regeln dafür, wer was bauen darf, wie Berechtigungen vergeben werden und wie Datenflüsse dokumentiert sind – also eine bewusste Steuerungsdisziplin, die ein etabliertes ERP-Consulting früh adressieren sollte.

Schließlich ist die Kehrseite der engen Verzahnung eine gewisse Bindung an das Ökosystem. Der Integrationsvorteil entfaltet sich vollständig nur, solange man sich innerhalb der Microsoft-Welt bewegt. An der Grenze zu Nicht-Microsoft-Systemen endet die mühelose Kopplung, und es beginnt wieder reguläre Schnittstellenarbeit über die Standard-APIs. Wer große Teile seiner Landschaft außerhalb dieser Welt betreibt, realisiert nur einen Teil des beschriebenen Mehrwerts und sollte dies in seiner Bewertung nüchtern berücksichtigen.

Unter dem Strich ist die Einbettung von Business Central in Power Platform, Microsoft 365 und Azure weit mehr als ein Marketingversprechen: Sie ist eine durchdachte Nabe-Speiche-Architektur, die das ERP in die alltägliche Arbeitsumgebung, in die Auswertung und in die Automatisierung integriert und auf einem gemeinsamen Plattformfundament ruhen lässt. Für bestehende Microsoft-Anwender ist das oft das stärkste Einzelargument überhaupt. Die Kunst besteht darin, diesen Vorteil zu nutzen, ohne die Lizenz- und Komplexitätsfolgen aus dem Blick zu verlieren – denn nur eine bewusst gesteuerte Integration bleibt auf Dauer der Mehrwert, der sie im günstigen Fall sein kann.

Häufige Fragen