Navision Software: Funktionsumfang und Module

Unter „Navision Software“ verstehen viele heute Microsoft Dynamics 365 Business Central. Dieser Beitrag beschreibt den Funktionsumfang, die wichtigsten Module sowie Editionen, Betrieb und Anpassbarkeit der Lösung.

Module und Funktionsumfang

Als integriertes ERP-System deckt die Software die zentralen Geschäftsprozesse mittelständischer Unternehmen ab. Der Funktionsumfang im Überblick:

Editionen und Betrieb

Business Central wird typischerweise in den Editionen Essentials (Finanzen, Verkauf, Einkauf, Lager, Projekte) und Premium (zusätzlich Produktion und Servicemanagement) angeboten. Der Betrieb erfolgt wahlweise in der Cloud (SaaS, regelmäßige Updates durch Microsoft) oder On-Premise. Lizenziert wird in der Regel pro Nutzer.

Anpassbarkeit

Die Software lässt sich über Konfiguration und über Erweiterungen (Extensions/AppSource) an individuelle Anforderungen anpassen, ohne den Standard zu verändern – das erleichtert spätere Updates. Branchen- und Zusatzlösungen von Partnern erweitern den Funktionsumfang gezielt.

Lohnt sich die Software für Sie?

Ob die Lösung passt, zeigt der Abgleich mit Ihrem Lastenheft und eine Demo mit eigenen Praxisfällen. Achten Sie neben der Software besonders auf den Implementierungspartner – er prägt den Projekterfolg oft stärker als das Produkt selbst.

Integration in die Microsoft-Welt

Ein wesentliches Unterscheidungsmerkmal der Navision-Nachfolge Business Central ist die enge Verzahnung mit dem übrigen Microsoft-Ökosystem. Belege lassen sich direkt aus Outlook heraus erfassen, Auswertungen in vertrauter Umgebung mit Excel bearbeiten und Kennzahlen über Power BI in interaktiven Dashboards darstellen. Für Unternehmen, die bereits auf Microsoft 365 setzen, senkt diese Integration die Einstiegshürde spürbar, weil die Anwender in einer gewohnten Oberfläche arbeiten. Auch die Anbindung an Teams und die Automatisierung über die Power Platform eröffnen Möglichkeiten, die über den klassischen ERP-Funktionsumfang hinausgehen.

Technisch wird die Software über sogenannte Extensions erweitert, die sauberen, updatesicheren Zusatzcode bereitstellen, ohne den Standard zu verändern. Über den Marktplatz Microsoft AppSource stehen zahlreiche Branchen- und Speziallösungen von Partnern bereit, die sich bei Bedarf hinzufügen lassen. Dieses Erweiterungskonzept ist ein wichtiger Vorteil: Es verbindet die Vorteile einer Standardlösung – Updatefähigkeit und Stabilität – mit der Möglichkeit gezielter Anpassung an die eigenen Anforderungen.

Lizenzierung verstehen

Die Lizenzierung erfolgt in der Regel pro benannten Nutzer, wobei zwischen vollwertigen Lizenzen und günstigeren Lizenzen für gelegentliche Nutzer unterschieden wird. Welche Edition und welche Lizenzart sinnvoll sind, hängt von den Rollen im Unternehmen ab. Da Microsoft Editionen, Funktionsumfang und Preismodelle gelegentlich anpasst, sollten die aktuellen Angaben des Herstellers oder Partners die Grundlage jeder Kalkulation bilden.

Technische Architektur und Erweiterbarkeit

Ein wesentliches Merkmal der Navision-Nachfolge Business Central ist ihr modernes Erweiterungskonzept. Anpassungen erfolgen über sogenannte Extensions, die in der Programmiersprache AL entwickelt werden und sauber vom Standard getrennt bleiben. Dadurch verändern Erweiterungen den Kern nicht direkt, was Updates erheblich erleichtert – ein wichtiger Unterschied zu früheren Generationen, bei denen tiefe Eingriffe spätere Aktualisierungen erschwerten. Über den Marktplatz Microsoft AppSource lassen sich zudem fertige Branchen- und Zusatzlösungen von Partnern hinzufügen.

Diese Architektur verbindet die Stabilität einer Standardsoftware mit der Möglichkeit gezielter Anpassung. Für Unternehmen bedeutet das: Individuelle Anforderungen lassen sich abbilden, ohne die Updatefähigkeit zu opfern – vorausgesetzt, Anpassungen werden konsequent über Extensions statt über Eingriffe in den Standard umgesetzt.

Auswertungen und Reporting

Für die Steuerung eines Unternehmens sind verlässliche Auswertungen entscheidend. Business Central bringt eingebaute Berichte und Kennzahlen mit und lässt sich eng mit Power BI verbinden, das interaktive Dashboards aus den ERP-Daten erzeugt. Daten lassen sich zudem komfortabel nach Excel übernehmen, was vielen Anwendern den Einstieg erleichtert. Wichtig ist, das Reporting früh im Projekt zu durchdenken: Welche Kennzahlen braucht die Geschäftsführung, welche die Fachbereiche, und wie müssen Daten dafür erfasst werden? Ein durchdachtes Auswertungskonzept stellt sicher, dass das System nicht nur Daten sammelt, sondern echten Steuerungsnutzen liefert. Wie man eine Lösung vor der Entscheidung praktisch prüft, beschreibt die Seite Navision Demo.

Sicherheit, Rollen und Berechtigungen

Als zentrales System mit sensiblen kaufmännischen und personenbezogenen Daten verlangt Business Central ein durchdachtes Berechtigungskonzept. Über Rollen und Berechtigungssätze lässt sich genau steuern, welche Mitarbeitenden welche Daten sehen und welche Aktionen sie ausführen dürfen. So erhält etwa der Vertrieb Zugriff auf Aufträge und Kunden, während sensible Finanzdaten auf die Buchhaltung beschränkt bleiben. Ein sauber gepflegtes Rollenkonzept schützt nicht nur vor Fehlern, sondern ist auch eine Anforderung des Datenschutzes.

Als Cloud-Lösung profitiert Business Central zudem von der Sicherheitsinfrastruktur der Microsoft-Plattform, einschließlich Authentifizierung über Microsoft-Konten, mehrstufiger Anmeldung und regelmäßiger Updates. Beim On-Premise-Betrieb liegt die Verantwortung für Absicherung, Backups und Aktualisierungen dagegen beim Unternehmen selbst. Unabhängig vom Betriebsmodell sollte das Berechtigungskonzept früh im Projekt durchdacht und nicht erst nachträglich aufgesetzt werden, da es eng mit den Prozessen und der Organisationsstruktur verknüpft ist. Regelmäßige Überprüfungen stellen sicher, dass Berechtigungen mit personellen Veränderungen Schritt halten und keine unnötigen Zugriffe bestehen bleiben.

Backups und Ausfallsicherheit

Da ein ERP-System geschäftskritisch ist, gehören Backups und Ausfallsicherheit zu den zentralen Betriebsthemen. In der Cloud-Variante von Business Central übernimmt Microsoft die Datensicherung und sorgt für eine hohe Verfügbarkeit der Plattform, was die eigene IT spürbar entlastet. Beim On-Premise-Betrieb liegt diese Verantwortung dagegen vollständig beim Unternehmen: Es muss regelmäßige Sicherungen, deren Überprüfung und einen Wiederanlaufplan selbst organisieren. Unabhängig vom Modell sollte klar geregelt sein, wie schnell das System nach einer Störung wieder verfügbar ist und wie weit zurückliegende Daten im Notfall wiederhergestellt werden können. Ein durchgespielter Notfallplan gibt Sicherheit, bevor der Ernstfall eintritt. Diese Vorsorge wirkt im Alltag unsichtbar, entscheidet aber im Krisenfall darüber, ob ein Zwischenfall eine kurze Unterbrechung oder ein ernstes Problem wird.

Zugriff per Web, App und Desktop

Ein praktischer Vorzug von Business Central ist die Flexibilität beim Zugriff. Anwender arbeiten wahlweise über den Webbrowser, über eine mobile App für Smartphone und Tablet oder über die Integration in Outlook – stets mit denselben Daten und einer einheitlichen Oberfläche. Das erlaubt ortsunabhängiges Arbeiten, etwa eine Freigabe unterwegs oder die Erfassung im Lager per Tablet. Da die Cloud-Variante keine lokale Installation erfordert, sind neue Nutzer schnell startklar. Bei der Einführung lohnt es sich zu klären, welche Rollen welchen Zugriffsweg benötigen, um Schulung und Berechtigungen passend zuzuschneiden. Diese Zugänglichkeit senkt Einstiegshürden und unterstützt moderne, flexible Arbeitsformen im gesamten Unternehmen.

Die Module im Überblick

Als integrierte Unternehmenssoftware deckt die Navision-Nachfolge (heute Business Central) die zentralen kaufmännischen Bereiche ab. Die wichtigsten Modulgruppen:

Betriebsmodelle und Editionen

Die Software ist als Cloud-Dienst und als On-Premise-Installation verfügbar. Der Funktionsumfang lässt sich über Branchenlösungen und Erweiterungen aus dem Partnernetz gezielt ergänzen, ohne den Standard zu verändern.

Stärken und Grenzen

Worauf Sie bei der Bewertung achten

• Deckt der Standard Ihre Kernprozesse ab?
• Sind die benötigten Schnittstellen vorhanden?
• Bleiben Anpassungen über Extensions updatefähig?
• Passt das Lizenzmodell zu Ihrer Nutzerstruktur?
• Hat der Partner Erfahrung in Ihrer Branche?

Lokalisierung für den deutschen Markt: DATEV, GoBD und E-Rechnung

Ob eine ERP-Software für den deutschen Mittelstand taugt, entscheidet sich nicht allein an ihrem Funktionsumfang, sondern an einer scheinbar unscheinbaren Eigenschaft: der Lokalisierung. Gemeint ist damit die Anpassung des Produkts an das jeweilige nationale Rechts-, Steuer- und Buchhaltungsregime. Microsoft Dynamics 365 Business Central wird für jedes Land in einer eigenen Lokalisierungsvariante ausgeliefert, und die deutsche Version – die German Localization – bringt genau jene Vorkehrungen mit, die das Produkt für die Pflichten des deutschen Steuer- und Handelsrechts überhaupt einsetzbar machen. Dieser Abschnitt behandelt ausschließlich die regulatorische Eignung im DACH-Raum: GoBD-Konformität, die Anbindung an die DATEV-Welt des Steuerberaters, die Umsatzsteuer-Voranmeldung über ELSTER, den Datenexport nach GoBD/GDPdU sowie die seit 2025 greifende E-Rechnungspflicht im B2B-Geschäft. Es geht hier nicht um Module, Reporting oder allgemeinen Leistungsumfang, sondern um die Frage, ob und wie das System die deutschen Vorschriften technisch und prozessual abbildet.

Wer die Software auswählt, sollte diese Ebene früh prüfen, denn sie ist nur begrenzt nachträglich reparierbar. Eine international gepflegte ERP-Plattform kann funktional brillant und dennoch für den deutschen Einsatz unbrauchbar sein, wenn die Lokalisierung fehlt oder nur rudimentär ausfällt. Bei Business Central liefert Microsoft die deutsche Variante als gepflegten Bestandteil des Standards – das ist ein wesentlicher Unterschied zu Lösungen, bei denen die Rechtskonformität vollständig dem Anwender oder dem Implementierungspartner aufgebürdet wird. Wie ausgeprägt diese Lokalisierung in der Praxis sein muss, ist deshalb ein zentrales Kriterium jeder ERP-Auswahl im deutschsprachigen Raum.

Was „deutsche Lokalisierung“ bei Business Central konkret bedeutet

Die German Localization ist kein loses Zusatzpaket, sondern eine vollwertige Länderversion mit eigenem Kontenrahmen-Vorschlag, deutschsprachiger Oberfläche, landesspezifischen Buchungsregeln und einer Reihe gesetzlich geforderter Auswertungen. Microsoft pflegt diese Variante im Rahmen der halbjährlichen Release Waves mit und passt sie an, wenn sich die rechtlichen Rahmenbedingungen ändern – etwa bei einer Änderung der Umsatzsteuersätze, neuen Meldeformaten oder eben der Einführung der E-Rechnung. Dieser kontinuierliche Pflegeaufwand ist der eigentliche Wert der Lokalisierung: Der Gesetzgeber bewegt sich, und das Produkt muss mitziehen, ohne dass jeder Anwender die Änderungen selbst nachbauen muss.

Konkret umfasst die deutsche Lokalisierung im Standard unter anderem die Unterstützung handelsrechtlicher Buchungslogik, die für Deutschland typischen Umsatzsteuer-Mechanismen einschließlich Reverse-Charge und innergemeinschaftlicher Lieferungen, vorbereitete steuerliche Auswertungen sowie Exportformate für die Zusammenarbeit mit Finanzverwaltung und Steuerberater. Damit deckt der Standard das Fundament ab. Für bestimmte, in Deutschland besonders ausgeprägte Anforderungen – allen voran die tiefe, komfortable DATEV-Integration – setzen jedoch spezialisierte Partner-Erweiterungen an, die über das hinausgehen, was Microsoft generisch liefern kann. Diese Arbeitsteilung zwischen Standard und Partner-App zieht sich durch das gesamte Thema und ist für die Bewertung der regulatorischen Eignung entscheidend.

GoBD-konforme Belegerfassung und Unveränderbarkeit

Die GoBD – die „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff“ – sind das zentrale Regelwerk, an dem sich jede buchführungsrelevante Software in Deutschland messen lassen muss. Im Kern verlangen sie, dass Geschäftsvorfälle vollständig, richtig, zeitgerecht und geordnet erfasst werden und dass einmal gebuchte Daten nicht mehr unbemerkt verändert oder gelöscht werden können. Eine nachträgliche Korrektur muss als solche erkennbar bleiben; der ursprüngliche Zustand und die Änderung müssen nachvollziehbar dokumentiert sein. Dieses Prinzip der Unveränderbarkeit und der lückenlosen Nachvollziehbarkeit ist der Dreh- und Angelpunkt der GoBD.

Business Central bildet diese Anforderung über mehrere ineinandergreifende Mechanismen ab. Gebuchte Belege werden nicht überschrieben, sondern erzeugen feste Buchungsposten, die nicht mehr editierbar sind; Korrekturen erfolgen über Stornierungen und Gegenbuchungen, die als eigene Vorgänge protokolliert werden und den ursprünglichen Posten bestehen lassen. Buchungsbelege erhalten fortlaufende Nummern aus definierten Nummernserien, sodass sich Lücken oder Dopplungen erkennen lassen. Das System führt über den Belegfluss hinweg einen Audit Trail, der dokumentiert, wer wann welchen Vorgang ausgelöst hat. Damit ist die Grundforderung der GoBD – Festschreibung und Nachvollziehbarkeit gebuchter Vorgänge – im Standard angelegt.

Wichtig ist allerdings eine saubere Abgrenzung von Anspruch und Realität. Eine Software ist nicht „GoBD-zertifiziert“ in dem Sinne, dass ihr bloßer Einsatz die Ordnungsmäßigkeit garantiert. Die GoBD richten sich an das buchführungspflichtige Unternehmen, nicht an das Produkt. Business Central stellt die technischen Voraussetzungen bereit, damit ein Unternehmen GoBD-konform arbeiten kann – doch entscheidend bleiben die Konfiguration, die Prozessgestaltung und die organisatorischen Regelungen. Dazu gehört eine schriftlich fixierte Verfahrensdokumentation, die beschreibt, wie Belege entstehen, erfasst, verarbeitet und aufbewahrt werden. Diese Dokumentation ist eine GoBD-Pflicht, die kein ERP-System automatisch erfüllt; sie ist Teil der Einführungs- und Betriebsorganisation. Die ERP-Software liefert das Werkzeug, die ordnungsgemäße Anwendung verantwortet das Unternehmen.

Die DATEV-Schnittstelle: Brücke zum Steuerberater

Kaum eine andere Anforderung ist für den deutschen Mittelstand so prägend wie die Anbindung an DATEV. Ein sehr großer Teil der deutschen Unternehmen lässt die Finanzbuchhaltung oder zumindest den Jahresabschluss durch einen Steuerberater erstellen, und Steuerberater arbeiten in aller Regel mit DATEV-Software. Für die ERP-Lösung im Unternehmen bedeutet das: Die Buchungsdaten müssen in einem Format bereitgestellt werden, das der Steuerberater ohne Reibungsverluste einlesen kann. Genau hier liegt einer der praktisch wichtigsten Berührungspunkte zwischen dem ERP-System und der externen Buchhaltungswelt.

Der etablierte Übergabeweg ist das DATEV-Format (oft als „DATEV ASCII“ bzw. nach dem aktuellen Standard als DATEV-Format bezeichnet), über das Buchungsstapel, Debitoren- und Kreditorenstammdaten sowie Sachkontenbewegungen exportiert werden. Hier ist eine ehrliche Differenzierung nötig: Ein grundlegender DATEV-Export lässt sich auf Basis der Buchungsdaten von Business Central abbilden, doch eine wirklich komfortable, bidirektionale und feldgenaue DATEV-Integration – mit korrekter Behandlung von Buchungsschlüsseln, Belegfeldern, BU-Schlüsseln, OPOS-Abstimmung und der laufenden Anpassung an DATEV-Formatänderungen – wird in der Praxis überwiegend durch Partner-Erweiterungen realisiert. Mehrere im deutschen Markt etablierte AppSource-Apps spezialisieren sich genau darauf, die sogenannte DATEV-Komfortschnittstelle bereitzustellen und sie aktuell zu halten.

Diese Aufgabenteilung ist kein Mangel, sondern Ausdruck der Spezialisierung: Microsoft liefert die buchhalterische Basis, die deutschen Partner liefern die Tiefenintegration in das DATEV-Ökosystem, das einem eigenen, sich verändernden Regelwerk folgt. Bei der Konzeption der ERP-Lösung sollte die DATEV-Anbindung deshalb von Anfang an als eigener Baustein mitgedacht werden – inklusive der Frage, ob der Steuerberater Daten nur empfängt oder ob ein wechselseitiger Abgleich gewünscht ist. Die Wahl der passenden DATEV-App und ihre Abstimmung mit der Kanzlei gehören zu den Punkten, die in der Einführungsphase früh geklärt werden, weil sie den gesamten Monatsabschluss-Prozess prägen.

Umsatzsteuer-Voranmeldung über ELSTER

Die regelmäßige Umsatzsteuer-Voranmeldung ist für die meisten Unternehmen eine monatliche oder vierteljährliche Pflicht, die ausschließlich elektronisch über das Verfahren ELSTER der Finanzverwaltung erfolgt. Die ERP-Software muss dafür die umsatzsteuerlich relevanten Bewegungen korrekt erfassen, den Vorsteuer- und Umsatzsteuersaldo ermitteln und die Werte in die richtigen Kennziffern der Voranmeldung überführen. Business Central bildet die deutsche Umsatzsteuer-Systematik im Rahmen der Lokalisierung ab: Steuerkennzeichen und Buchungsmatrizen ordnen jedem Geschäftsvorfall den passenden Steuersatz und die zutreffende rechtliche Behandlung zu – einschließlich der Sonderfälle wie Reverse-Charge bei Leistungsbezug aus dem Ausland oder steuerfreie innergemeinschaftliche Lieferungen.

Aus diesen Buchungen lässt sich die Voranmeldung als steuerliche Auswertung erzeugen. Bei der eigentlichen Übermittlung an das Finanzamt zeigt sich erneut das Zusammenspiel von Standard und Ergänzung: Die elektronische Einreichung über die ELSTER-Schnittstelle, die korrekte Erzeugung der amtlich vorgeschriebenen XML-Struktur und die laufende Pflege bei Formularänderungen werden in der deutschen Praxis häufig über spezialisierte Funktionen oder Partner-Apps abgewickelt; in vielen Konstellationen übernimmt ohnehin der Steuerberater die finale Übermittlung auf Basis der übergebenen Buchungsdaten. Entscheidend für die regulatorische Eignung ist, dass die zugrunde liegenden umsatzsteuerlichen Daten im System korrekt, vollständig und revisionssicher entstehen – und das leistet die Lokalisierung. Verwandte Pflichten wie die Zusammenfassende Meldung für innergemeinschaftliche Umsätze folgen demselben Muster aus korrekter Erfassung im Standard und formatkonformer Übermittlung.

GoBD-/GDPdU-Datenexport für die Betriebsprüfung

Eine weitere genuin deutsche Anforderung betrifft den Datenzugriff der Finanzverwaltung im Rahmen einer Außenprüfung. Historisch unter dem Begriff GDPdU bekannt und heute im GoBD-Regelwerk aufgegangen, verlangt diese Vorschrift, dass steuerlich relevante Daten in einer maschinell auswertbaren Form bereitgestellt werden können. Der Prüfer erwartet einen strukturierten Datenexport, den er mit der amtlichen Prüfsoftware (IDEA) einlesen und auswerten kann – typischerweise als Datensatzbeschreibung mit zugehörigen Bewegungsdaten in einem definierten Format.

Business Central unterstützt im Rahmen der deutschen Lokalisierung den Export steuerlich relevanter Daten in einem für die Prüfung geeigneten Format, sodass die im System geführten Buchungs- und Belegdaten der Finanzverwaltung in der geforderten Struktur übergeben werden können. Auch hier gilt: Der Standard liefert die Grundlage, doch Umfang, Feldzuordnung und die exakte Aufbereitung für einen konkreten Prüfungsfall werden in der Praxis je nach Anforderung verfeinert – teils über Konfiguration, teils über Partner-Erweiterungen, die den Export komfortabler und vollständiger gestalten. Für ein Unternehmen, das eine Software im Mittelstand betreibt, ist die Prüfungsfestigkeit dieses Exports ein Punkt, der nicht erst im Ernstfall der Betriebsprüfung getestet werden sollte, sondern bereits beim Aufbau des Systems.

E-Rechnungspflicht im B2B ab 2025: XRechnung, ZUGFeRD und EN 16931

Die jüngste und für viele Unternehmen folgenreichste regulatorische Neuerung ist die E-Rechnungspflicht im inländischen B2B-Geschäft. Seit dem 1. Januar 2025 gilt in Deutschland ein neuer Rechnungsbegriff: Als elektronische Rechnung zählt künftig nur noch eine Rechnung, die in einem strukturierten, maschinenlesbaren Format nach der europäischen Norm EN 16931 ausgestellt, übermittelt und empfangen wird. Eine PDF-Datei oder ein eingescanntes Papierdokument gilt in diesem Sinne nicht mehr als E-Rechnung, sondern als „sonstige Rechnung“. Die Einführung erfolgt gestuft: Seit Anfang 2025 müssen inländische B2B-Unternehmen E-Rechnungen empfangen können – diese Empfangspflicht greift ohne Übergangsfrist. Für das Ausstellen gelten gestaffelte Übergangsregelungen, die in den Folgejahren auslaufen, sodass die strukturierte Rechnung schrittweise zur verbindlichen Regel im B2B wird.

In Deutschland haben sich zwei normkonforme Formate etabliert: XRechnung, ein rein strukturiertes XML-Format, das ursprünglich für den öffentlichen Auftraggeber entwickelt wurde, und ZUGFeRD, ein hybrides Format, das ein menschenlesbares PDF mit eingebetteten strukturierten XML-Daten kombiniert. Beide erfüllen die Vorgaben der EN 16931. Für die ERP-Software bedeutet die Pflicht zweierlei: Sie muss ausgehende Rechnungen im strukturierten Format erzeugen und eingehende strukturierte Rechnungen einlesen und weiterverarbeiten können – idealerweise so, dass die Daten direkt in die Eingangsrechnungsverarbeitung fließen, statt manuell abgetippt zu werden.

Business Central bringt im Rahmen der internationalen und deutschen Lokalisierung eine Grundlage für den Umgang mit elektronischen Dokumenten und E-Invoicing mit; Microsoft hat das Produkt im Zuge der europaweiten E-Rechnungs-Initiativen entsprechend erweitert. Für die konkrete, format- und prozesssichere Umsetzung der deutschen Anforderungen – die exakte XRechnung-Profilierung, die ZUGFeRD-Erzeugung, die Validierung gegen die Norm sowie die Anbindung an Versand- und Empfangswege – greifen viele Unternehmen jedoch auf spezialisierte Partner-Apps zurück. Diese decken die Feinheiten der deutschen Formatprofile ab und werden bei Normänderungen nachgeführt. Die E-Rechnung ist damit ein Musterbeispiel für das Zusammenspiel: Der Standard schafft die Anschlussfähigkeit, die deutschen Partner liefern die format- und rechtssichere Tiefe. Da die Empfangspflicht bereits ohne Übergangsfrist gilt, gehört dieses Thema zu den Punkten, die bei einer ERP-Implementierung nicht aufgeschoben werden dürfen.

Die folgende Übersicht ordnet die einzelnen Anforderungen danach, wo sie heute typischerweise abgedeckt werden – im Standard, über eine Partner-App oder bislang manuell – und nennt jeweils die praktische Umsetzung. Sie ist als Orientierung gedacht; die konkrete Abdeckung hängt von Release-Stand, gewählten Apps und Konfiguration ab.

Was das für die Bewertung der regulatorischen Eignung bedeutet

Zieht man die einzelnen Stränge zusammen, ergibt sich ein klares Bild: Business Central ist über die deutsche Lokalisierung grundsätzlich für den Einsatz im deutschen Rechts- und Steuerumfeld geeignet, und Microsoft pflegt diese Eignung kontinuierlich mit den Release Waves nach. Das Fundament – ordnungsmäßige, unveränderbare Belegerfassung, deutsche Umsatzsteuer-Systematik, steuerlich verwertbarer Datenexport und die Anschlussfähigkeit für E-Rechnung und DATEV – liegt im Standard. Zugleich zeigt sich an mehreren Stellen ein wiederkehrendes Muster: Dort, wo die deutschen Anforderungen besonders detailreich und einem eigenen, sich wandelnden Regelwerk unterworfen sind – DATEV-Komfortschnittstelle, format­sichere E-Rechnung, prüfungsfester Export, Langzeitarchivierung –, ergänzen spezialisierte Partner-Erweiterungen den Standard und sorgen für die nötige Tiefe und Aktualität.

Für die Entscheidung heißt das: Die Frage „Ist die Software für Deutschland geeignet?“ lässt sich nicht mit einem schlichten Ja oder Nein beantworten, sondern nur als Frage nach der konkreten Konfiguration. Geeignet ist die Lösung dann, wenn die deutsche Lokalisierung aktiv ist, die passenden Partner-Apps für DATEV und E-Rechnung ausgewählt und abgestimmt sind und die organisatorischen Pflichten – allen voran die Verfahrensdokumentation – erfüllt werden. Diese Prüfung gehört an den Anfang jedes Vorhabens und ist ein Kernbestandteil eines fundierten ERP-Consultings im DACH-Raum. Wer sie ernst nimmt, vermeidet die typische Falle, ein funktional starkes System einzuführen und erst im laufenden Betrieb oder gar in der Betriebsprüfung festzustellen, dass eine zentrale regulatorische Anforderung nicht sauber abgebildet ist.

Abschließend sei die saubere Trennung betont, die diesen Abschnitt leitet: Hier ging es ausschließlich um die regulatorische Eignung – also darum, ob und wie das System deutsche Pflichten erfüllt. Wie sich diese Pflichtfunktionen technisch über Apps ergänzen lassen, wie der produktive Betrieb mit Mandanten und Umgebungen organisiert wird und wie der Weg von alten Navision-Beständen in die aktuelle Software führt, behandeln die übrigen Abschnitte dieser Seite. Die Lokalisierung ist die Eintrittskarte in den deutschen Markt; der eigentliche Mehrwert entsteht erst, wenn diese Karte gelöst ist und das System rechtssicher in den Buchhaltungs- und Steueralltag eingebettet wird.

Per-Tenant Extensions vs. AppSource-Apps: zwei Wege der Erweiterung

Sobald die grundsätzliche Frage geklärt ist, wie sich die Software technisch erweitern lässt – nämlich nicht mehr durch Eingriffe in den Standardcode, sondern über getrennt verwaltete Erweiterungen –, stellt sich eine zweite, mindestens ebenso folgenreiche Frage: woher diese Erweiterungen stammen und wer sie über die gesamte Lebensdauer hinweg pflegt. Genau an dieser Stelle trennen sich die beiden Wege, auf denen eine moderne Navision-Nachfolgelösung im laufenden Betrieb mit zusätzlicher Funktionalität versorgt wird: die individuell für einen einzigen Kunden gebaute Per-Tenant Extension (PTE) auf der einen Seite und die marktweit verfügbare, von Microsoft validierte AppSource-App auf der anderen. Beide setzen technisch auf derselben Erweiterungssprache AL auf und wirken aus Anwendersicht oft ununterscheidbar – ein zusätzliches Feld, ein neuer Beleg, eine neue Schnittstelle. Strategisch sind sie jedoch zwei völlig verschiedene Beschaffungs- und Wartungsmodelle mit unterschiedlichen Konsequenzen für Updatefähigkeit, Verantwortung, Kosten und Bindung an den jeweiligen Anbieter.

Dieser Abschnitt behandelt bewusst nicht das technische Fundament der Erweiterbarkeit – die Frage, warum Erweiterungen überhaupt getrennt vom Standard laufen und welche Schichten dabei ineinandergreifen, gehört in die Architekturbetrachtung. Hier geht es ausschließlich um die strategische Wahl des Bezugs- und Wartungsmodells: Welcher der beiden Wege passt zu welcher Anforderung, wer trägt jeweils das Risiko, und welche langfristigen Folgen ergeben sich daraus für ein Unternehmen, das seine Prozesse auf dieser Plattform abbildet? Wer diese Unterscheidung früh versteht, trifft bei jeder einzelnen Anpassung eine bewusste Entscheidung, statt unreflektiert immer denselben Weg zu gehen – und genau diese Bewusstheit ist ein zentraler Baustein einer tragfähigen ERP-Lösung.

Per-Tenant Extension: die maßgeschneiderte Anpassung für genau einen Mandanten

Eine Per-Tenant Extension ist eine Erweiterung, die ein Implementierungspartner – oder eine ausreichend qualifizierte interne Entwicklung – exklusiv für einen einzelnen Kunden baut und ausschließlich in dessen Mandanten installiert. Der Name ist hier Programm: Die Extension lebt per tenant, also pro Mandant, und existiert nirgendwo sonst. Sie wird nicht über einen öffentlichen Marktplatz vertrieben, nicht von Microsoft geprüft und steht keinem anderen Unternehmen zur Verfügung. Ihr Zweck ist die Abbildung genau jener Besonderheiten, die ein Betrieb gegenüber dem Standard hat: ein firmenspezifischer Genehmigungsworkflow, eine eigene Preisfindungslogik, ein zusätzliches Pflichtfeld auf dem Verkaufsbeleg, eine Schnittstelle zu einem Spezialsystem, das nur in dieser Branche oder gar nur in diesem Haus verwendet wird.

Der entscheidende Vorteil der PTE liegt in ihrer vollständigen Maßgeschneidertheit. Weil sie nur einen einzigen Adressaten hat, muss sie keine Rücksicht auf andere Kunden, andere Branchen oder generische Anwendungsfälle nehmen. Sie bildet exakt die Anforderung ab, die der Betrieb formuliert hat – nicht mehr und nicht weniger. Das macht PTEs zum natürlichen Werkzeug für jene Differenzierung, die ein Unternehmen vom Wettbewerb abhebt: Prozesse, die gerade nicht standardisiert sind, weil sie zum spezifischen Geschäftsmodell gehören. Der Preis dieser Passgenauigkeit ist allerdings, dass jede PTE ein Einzelstück ist. Es gibt keinen Hersteller, der sie weiterentwickelt, keine Community, die Fehler meldet, und keinen Marktplatz, der ihre Qualität bestätigt. Die gesamte Verantwortung für Funktion, Pflege und Anpassung an künftige Plattformversionen liegt bei demjenigen, der sie gebaut hat – in der Regel beim Partner, gelegentlich beim Kunden selbst.

Daraus folgt ein zentrales Merkmal, das in der laufenden Betreuung oft unterschätzt wird: Eine PTE ist nicht von Microsoft zertifiziert. Sie durchläuft keine externe Qualitätsprüfung und keinen technischen Validierungsprozess. Ihre Qualität ist exakt so gut wie die Arbeit der Personen, die sie geschrieben haben, und ihre Updatefähigkeit hängt davon ab, wie sauber sie an die Schnittstellen der Plattform angedockt wurde. Eine handwerklich gut gebaute PTE, die sich diszipliniert an die vorgesehenen Erweiterungspunkte hält, überlebt Plattform-Updates problemlos. Eine PTE, die mit fragwürdigen Mitteln tief in Standardabläufe eingreift, kann beim nächsten Update brechen – und dann ist der Kunde darauf angewiesen, dass der ursprüngliche Ersteller verfügbar ist und das Problem zeitnah behebt.

AppSource-App: das geprüfte, marktweit verfügbare Produkt

Den Gegenpol bildet die AppSource-App. Sie ist kein Einzelstück, sondern ein Produkt, das ein Softwarehersteller – ein sogenannter Independent Software Vendor – entwickelt, gepflegt und über Microsofts kommerziellen Marktplatz AppSource einem unbegrenzten Kreis von Kunden anbietet. Eine solche App löst typischerweise eine Aufgabe, die nicht nur ein einzelnes Unternehmen betrifft, sondern in einer ganzen Branche oder über viele Betriebe hinweg in ähnlicher Form auftritt: eine Anbindung an einen bestimmten Zahlungsdienstleister, eine Versand- oder Speditionsintegration, eine branchenspezifische Funktionserweiterung oder ein zusätzliches Reporting-Modul. Was die PTE durch Exklusivität erreicht, erreicht die AppSource-App durch Wiederverwendbarkeit und Standardisierung.

Bevor eine App im Marktplatz erscheint, durchläuft sie einen Validierungs- und Zertifizierungsprozess durch Microsoft. Geprüft werden unter anderem technische Sauberkeit, Einhaltung der Plattformkonventionen, korrektes Verhalten beim Installieren und Deinstallieren sowie die Verträglichkeit mit anderen Erweiterungen. Diese Zertifizierung ist der wesentliche Unterschied zur PTE: Sie ist kein Qualitätsversprechen für jeden Einzelfall, schafft aber eine geprüfte Grundverlässlichkeit und stellt sicher, dass die App nach den Regeln der Plattform spielt. Für ein Unternehmen bedeutet das eine deutlich geringere technische Unsicherheit, weil eine neutrale Instanz die App vor der Veröffentlichung kontrolliert hat. Wer im Rahmen einer strukturierten ERP-Auswahl Zusatzfunktionen evaluiert, kann zertifizierte Apps daher mit einer anderen Erwartungssicherheit behandeln als individuell zu beauftragende Sonderentwicklungen.

Der zweite prägende Unterschied betrifft die Pflege. Eine AppSource-App wird vom Hersteller als Produkt über ihren gesamten Lebenszyklus weiterentwickelt. Er liefert Updates, behebt Fehler für alle Kunden gleichzeitig, passt die App an neue Plattformversionen an und reagiert auf gesetzliche oder technische Änderungen. Der einzelne Kunde profitiert von dieser geteilten Wartung, ohne sie selbst tragen zu müssen – er ist einer von vielen, und die Pflegekosten verteilen sich über die gesamte Kundenbasis. Im Gegenzug gibt er die Kontrolle über den Funktionsumfang ab: Eine AppSource-App tut, was der Hersteller für sinnvoll hält, und individuelle Sonderwünsche eines einzelnen Kunden fließen allenfalls als Anregung in die Produktroadmap ein, nicht als verbindliche Anforderung.

Updatefähigkeit: warum der Bezugsweg über die Zukunftssicherheit entscheidet

Die wichtigste praktische Konsequenz beider Modelle zeigt sich beim regelmäßigen Plattform-Update. Microsoft veröffentlicht für die aktuelle Cloud-Generation mehrmals jährlich neue Versionen, und jede Erweiterung muss mit der jeweils neuen Basis funktionieren. Hier wirkt sich der unterschiedliche Pflegeweg unmittelbar aus. Bei einer AppSource-App ist es Aufgabe des Herstellers, seine App rechtzeitig vor jeder neuen Plattformversion zu testen und kompatibel zu halten. Versäumt er das, kann Microsoft die App im Extremfall daran hindern, in eine neue Umgebung zu wandern – der Druck zur Aktualität liegt also strukturell beim Anbieter, und der Kunde kann sich darauf verlassen, dass ein aktiver Hersteller seine Produkte fortlaufend nachzieht.

Bei der Per-Tenant Extension existiert dieser strukturelle Druck nicht. Niemand außer dem Ersteller hat ein Interesse daran, die Extension aktuell zu halten, und es gibt keine Instanz, die ihre Aktualität erzwingt. Die Updatefähigkeit hängt damit unmittelbar an einer organisatorischen Vereinbarung: Hat der Kunde mit seinem Partner einen Wartungsvertrag, der die laufende Pflege der individuellen Erweiterungen einschließt? Wird vor jedem Plattform-Update geprüft, ob die PTEs noch sauber funktionieren? Fehlt diese Vereinbarung, kann eine individuelle Erweiterung über die Jahre stillschweigend veralten, bis sie bei einem Update unerwartet bricht. Die Updatefähigkeit einer PTE ist daher keine technische Eigenschaft, sondern primär eine Frage der vertraglich abgesicherten Betreuung.

Daraus ergibt sich eine klare Faustregel für die Praxis: Je mehr individuelle PTEs ein Mandant ansammelt, desto wichtiger wird ein verlässlicher Pflegeprozess, der diese Erweiterungen aktiv mit der Plattform mitführt. Eine wachsende Zahl ungepflegter Sonderentwicklungen ist einer der häufigsten Gründe, warum eine eigentlich moderne Installation im Laufe der Zeit wieder schwerfällig und updatekritisch wird – also genau jene Falle, die das getrennte Erweiterungsmodell eigentlich vermeiden sollte. Dieser Aspekt gehört zwingend in jedes seriöse ERP-Consulting und sollte vor der ersten Sonderentwicklung geklärt sein, nicht erst beim ersten gebrochenen Update.

Verantwortung und Kosten: wer trägt was?

Die Frage der Verantwortung folgt unmittelbar aus dem Bezugsweg. Bei einer AppSource-App ist die Verantwortungskette klar geschnitten: Der Hersteller verantwortet das Produkt, Microsoft verantwortet die Plattform und die Zertifizierung, der Kunde verantwortet lediglich die korrekte Konfiguration und Nutzung. Treten Fehler in der App auf, ist der Ansprechpartner eindeutig der Hersteller. Bei einer PTE verdichtet sich die Verantwortung dagegen auf eine einzige Beziehung: die zwischen Kunde und Ersteller. Funktioniert die Extension nicht, gibt es keinen Produkt-Support einer dritten Partei – es gibt nur den Partner, der sie gebaut hat. Das ist solange unproblematisch, wie diese Beziehung stabil und das Wissen verfügbar ist, wird aber zum Risiko, sobald der Partner wechselt, das Projekt personell ausgedünnt wird oder die ursprüngliche Dokumentation fehlt.

Auf der Kostenseite unterscheiden sich beide Modelle grundlegend in der Struktur. Eine PTE verursacht einen projektbezogenen Entwicklungsaufwand: Sie wird einmal beauftragt und bezahlt, anschließend fallen Pflegekosten an, die in der Regel im laufenden Betreuungsvertrag mit dem Partner abgebildet werden. Weil die Extension exklusiv ist, trägt der eine Kunde die vollen Kosten ihrer Entwicklung und Pflege allein – es gibt keine Lizenzweitergabe an andere, weil es keine anderen Nutzer gibt. Eine AppSource-App verursacht dagegen typischerweise wiederkehrende Lizenz- oder Abonnementkosten, dafür verteilen sich die eigentlichen Entwicklungs- und Pflegekosten über die gesamte Kundenbasis des Herstellers. Der einzelne Kunde zahlt also einen Bruchteil dessen, was ihn eine vergleichbare Eigenentwicklung kosten würde – allerdings dauerhaft und ohne Eigentum an der Funktionalität zu erwerben.

Vereinfacht lässt sich der kaufmännische Gegensatz so fassen: Die PTE ist eine Investition in Exklusivität, die der Kunde allein finanziert und über die er die volle Kontrolle behält. Die AppSource-App ist der Bezug einer geteilten Leistung, bei der man sich Pflegeaufwand und Risiko mit vielen anderen teilt, dafür aber auf individuelle Gestaltungsfreiheit verzichtet. Welches Modell günstiger ist, lässt sich nicht pauschal beantworten – es hängt davon ab, wie standardisierbar die Anforderung ist und wie lange die Funktion benötigt wird.

Lock-in: zwei verschiedene Abhängigkeiten

Beide Wege erzeugen eine Abhängigkeit – allerdings eine jeweils anders gelagerte, und das Verständnis dieses Unterschieds ist für die strategische Entscheidung zentral. Die Per-Tenant Extension bindet den Kunden an den Partner, der sie gebaut hat. Solange die Extension läuft und niemand sie anfassen muss, ist diese Bindung unsichtbar. Sobald aber eine Änderung, eine Fehlerbehebung oder eine Update-Anpassung nötig wird, ist der Kunde auf dieses spezifische Wissen angewiesen. Ein Partnerwechsel bedeutet dann, dass der neue Partner sich erst in fremden, oft nur spärlich dokumentierten Code einarbeiten muss. Dieses Risiko lässt sich durch saubere Dokumentation, ordentliche Codequalität und die vertragliche Sicherung des Quellcode-Zugriffs deutlich abmildern – es verschwindet aber nicht völlig.

Die AppSource-App bindet den Kunden dagegen an den Hersteller und dessen Geschäftsmodell. Hier liegt das Risiko weniger im verlorenen Wissen als im Fortbestand und in der Preispolitik des Anbieters: Stellt der Hersteller die App ein, ändert er sein Lizenzmodell oder erhöht die Preise spürbar, ist der Kunde mit einer in seine Prozesse eingewachsenen Funktion konfrontiert, deren Bedingungen er nicht kontrolliert. Ein Vorteil bleibt jedoch: Weil die App standardisiert und marktweit verfügbar ist, existieren oft Alternativen, und ein Wechsel ist tendenziell besser planbar als bei einer hochindividuellen Eigenentwicklung. Wer den Markt zertifizierter Apps kennt, hat im Zweifel mehr Ausweichoptionen als jemand, dessen Kernprozess in einer einzigartigen PTE steckt.

Die strategische Entscheidung im Gesamtbild

Die Wahl zwischen Per-Tenant Extension und AppSource-App ist damit keine technische Detailfrage, sondern eine wiederkehrende strategische Weichenstellung, die bei jeder einzelnen Zusatzanforderung neu zu treffen ist. Sie lässt sich auf drei Leitfragen verdichten: Ist die Anforderung standardisierbar oder firmenspezifisch? Wer soll die Funktion über die Jahre pflegen – ein Hersteller oder der eigene Partner? Und welche Art von Abhängigkeit ist das Unternehmen bereit einzugehen – an einen Partner oder an einen Produktanbieter? Wer diese drei Fragen bei jeder Erweiterung bewusst beantwortet, baut über die Zeit eine Installation auf, in der Standardaufgaben durch gepflegte Produkte und echte Differenzierung durch gezielte Eigenentwicklungen abgedeckt sind.

Für den Mittelstand ergibt sich daraus eine pragmatische Grundhaltung: Sonderentwicklungen sind ein wertvolles Werkzeug, aber kein Selbstzweck. Jede PTE ist eine bewusste Investition in Exklusivität, die mit dauerhafter Pflegeverantwortung erkauft wird; jede AppSource-App ist der Verzicht auf individuelle Gestaltung zugunsten geteilter, geprüfter Wartung. Beide Wege haben ihre Berechtigung – entscheidend ist, dass sie nicht zufällig, sondern entlang dieser klaren Kriterien gewählt werden. Wer das von Beginn an diszipliniert handhabt, hält seine Navision-Nachfolgelösung dauerhaft schlank, updatefähig und beherrschbar, statt sie über die Jahre unbemerkt in ein schwer wartbares Geflecht aus ungepflegten Einzelstücken zurückzuverwandeln.

Umgebungen, Mandanten und Performance-Grenzen im Betrieb

Sobald die fachliche Eignung einer ERP-Software geklärt ist, stellt sich eine ganz andere, oft unterschätzte Frage: Wie ist das System im laufenden Betrieb eigentlich strukturiert, und wo liegen seine technischen Grenzen? Bei Microsoft Dynamics 365 Business Central in der Cloud-Variante (Software as a Service) ist diese Struktur nicht beliebig, sondern folgt einem festen Schichtenmodell aus Tenant, Umgebungen und Companies – und jede dieser Schichten bringt ein eigenes Mengengerüst mit, das festlegt, wie viele Daten, Mandanten, Schnittstellenaufrufe und Hintergrundprozesse das System verarbeiten kann. Dieser Abschnitt behandelt ausschließlich diese Skalierungsstruktur und ihre Grenzen. Es geht hier nicht um Lizenzpakete oder Editionen, nicht um Ausfallsicherheit und nicht um Datensicherung, sondern um die Frage, wie das System organisatorisch und technisch aufgebaut ist und ab welcher Datenmenge oder Nutzerzahl Speicher- und Performance-Themen real werden.

Wer eine ERP-Lösung betreibt, sollte dieses Gerüst früh verstehen, denn es entscheidet darüber, wie sich Tochtergesellschaften, Test- und Produktivbetrieb, externe Anbindungen und das Wachstum des Datenbestands abbilden lassen. Die Cloud-Architektur unterscheidet sich dabei grundlegend vom klassischen On-Premise-Betrieb der alten Navision-Welt, in der die Grenzen allein durch die eigene Server-Hardware gesetzt waren. In der Cloud setzt der Betreiber der Plattform die Leitplanken – und genau diese Leitplanken sind der Gegenstand der folgenden Betrachtung.

Die drei Schichten: Tenant, Umgebung und Company

Die oberste Ebene bildet der Tenant. Er ist die Identitäts- und Mandantenklammer eines Unternehmens und an das Microsoft-Entra-Verzeichnis (vormals Azure Active Directory) gebunden. Über den Tenant werden Benutzer, Anmeldung, Berechtigungen und die organisatorische Zugehörigkeit verwaltet; er ist gewissermaßen das digitale Grundstück, auf dem alles Weitere errichtet wird. Ein Unternehmen besitzt in der Regel genau einen Tenant, in dem sämtliche Cloud-Dienste – nicht nur das ERP, sondern auch E-Mail, Dateiablage und Kollaboration – zusammenlaufen.

Innerhalb des Tenants existieren Umgebungen (Environments). Eine Umgebung ist eine eigenständige, in sich abgeschlossene Instanz der Anwendung mit eigener Datenbank. Hier wird die fundamentale Unterscheidung zwischen Production und Sandbox getroffen: Die Produktivumgebung ist das System, in dem real gearbeitet wird – hier entstehen echte Buchungen, echte Belege, echte Geschäftsvorfälle. Eine Sandbox dagegen ist eine isolierte Spielwiese, in der getestet, geschult, entwickelt und ausprobiert werden kann, ohne den Produktivbetrieb zu gefährden. Sandboxes lassen sich aus einer Kopie der Produktivdaten erzeugen, sodass Tests unter realistischen Bedingungen stattfinden, oder leer und mit Demodaten aufsetzen. Entscheidend ist die strikte Trennung: Was in der Sandbox geschieht, berührt die Produktion nicht.

Die unterste fachliche Ebene schließlich ist die Company, im deutschen Sprachgebrauch der Mandant. Eine Umgebung kann mehrere Companies enthalten, und jede Company ist ein eigenständiger buchhalterischer und betriebswirtschaftlicher Raum mit eigenem Kontenrahmen, eigenen Stammdaten, eigenen Belegnummern und eigener Bilanz. Genau hier liegt der Hebel für Konzern- und Gruppenstrukturen: Eine Holding mit mehreren rechtlich selbstständigen Gesellschaften kann diese als getrennte Mandanten in einer gemeinsamen Umgebung führen, gemeinsame Stammdaten zwischen ihnen abgleichen und dennoch jede Gesellschaft sauber separat bilanzieren. Innerhalb der Company liegen schließlich die eigentlichen Daten und Tabellen – die Buchungsposten, Artikel, Debitoren, Kreditoren und Belege, die das Mengengerüst überhaupt erst füllen.

Datenbankkapazität: das zentrale Mengengerüst

Die wohl wichtigste technische Grenze betrifft die Datenbankkapazität. In der Cloud-Variante wird jedem Tenant ein Grundkontingent an Datenbankspeicher zugestanden, das sich aus den erworbenen Lizenzen ableitet. Das Prinzip ist gestaffelt: Es gibt eine Basismenge, die jeder Tenant erhält, und ein zusätzliches Volumen, das mit jedem erworbenen Vollbenutzer mitwächst. Je mehr lizenzierte Benutzer ein Unternehmen also hat, desto größer fällt das verfügbare Datenbankvolumen aus. Dieses Kontingent ist eine harte Schwelle: Wird es überschritten, lässt das System bestimmte Vorgänge nicht mehr zu – Daten lassen sich dann nicht mehr ohne Weiteres anlegen, bis entweder aufgeräumt oder Kapazität nachgekauft wird.

Genau dafür existiert der Speicher-Zukauf. Reicht das aus den Lizenzen abgeleitete Volumen nicht aus, kann zusätzlicher Datenbankspeicher in definierten Paketen kostenpflichtig hinzugebucht werden. Das ist ein wesentlicher Unterschied zur On-Premise-Welt: Dort war Speicher eine Frage der eigenen Festplatten und damit faktisch beliebig erweiterbar, solange die Hardware mitspielte. In der Cloud ist Speicher ein bewirtschaftetes, abrechenbares Gut. Diese Bewirtschaftung zwingt zu einer Disziplin, die im eigenen Rechenzentrum oft fehlte: Wer welche Datenmengen über welche Zeiträume vorhält, wird zur betriebswirtschaftlichen Entscheidung, nicht nur zur technischen.

Ein häufig übersehener Punkt: Nicht nur die Produktivdaten zählen auf das Datenbankkontingent ein, sondern grundsätzlich auch der Speicherverbrauch der Umgebungen insgesamt. Wer großzügig mehrere datenreiche Sandboxes als Kopie der Produktion betreibt, sollte im Blick behalten, dass diese ebenfalls Kapazität beanspruchen. Eine bewusste Trennung zwischen schlanken Test-Sandboxes und vollständigen Kopien hilft, das Kontingent nicht unbemerkt auszuschöpfen.

Anzahl der Sandboxes und ihre Rolle

Die Zahl der parallel betreibbaren Sandbox-Umgebungen ist ebenfalls begrenzt. Während die Produktivumgebung in der Regel die einzige ihrer Art bleibt, dürfen mehrere Sandboxes nebeneinander existieren – allerdings nicht beliebig viele. Diese Begrenzung ist selten ein praktisches Problem, weil die meisten Unternehmen mit einer überschaubaren Zahl an Testumgebungen auskommen: typischerweise eine für die laufende Entwicklung und das Customizing, eine für Schulung und Abnahmetests sowie gegebenenfalls eine kurzlebige Umgebung, um ein anstehendes Plattform-Update vorab zu prüfen. Sandboxes sind nicht nur eine technische Spielwiese, sondern ein zentrales Werkzeug der gesamten ERP-Implementierung: In ihnen werden Anpassungen entwickelt, Datenübernahmen geprobt und Prozesse abgenommen, bevor irgendetwas die Produktivumgebung berührt.

Wichtig ist das Bewusstsein für die unterschiedliche Leistungszuteilung: Sandboxes laufen typischerweise mit geringerer Rechenleistung als die Produktivumgebung und eignen sich daher nicht, um realistische Lasttests bei sehr großen Datenmengen durchzuführen. Sie zeigen, ob ein Prozess funktioniert, aber nicht zuverlässig, wie schnell er unter Volllast in der Produktion abläuft. Diese Unterscheidung sollte man kennen, bevor man aus Sandbox-Beobachtungen voreilige Performance-Schlüsse zieht.

API- und Webservice-Limits

Eine moderne ERP-Software lebt nicht isoliert, sondern ist über Schnittstellen mit Webshops, Versanddienstleistern, Bankanbindungen, Branchenlösungen und anderen Systemen verbunden. Diese Integration läuft über APIs und Webservices, und auch hier setzt die Cloud-Plattform Grenzen – aus gutem Grund: In einer mandantenfähigen Umgebung, in der viele Kunden dieselbe Infrastruktur teilen, müssen Schnittstellenaufrufe gedrosselt werden, damit ein einzelnes System die gemeinsame Plattform nicht überlastet. Dieses Prinzip nennt sich Throttling: Es gibt Obergrenzen für die Zahl gleichzeitiger Verbindungen und für die Menge an Aufrufen innerhalb eines Zeitfensters. Wird die Grenze überschritten, weist das System weitere Aufrufe vorübergehend ab und signalisiert dem aufrufenden System, es später erneut zu versuchen.

Für die Praxis bedeutet das: Integrationen müssen so gebaut sein, dass sie mit diesen Grenzen umgehen können – etwa durch Wiederholungslogik, durch Bündelung vieler Einzelvorgänge in Stapelverarbeitung und durch eine kluge Verteilung der Last über die Zeit. Ein Webshop, der bei jeder Bestellung mehrere Einzelaufrufe gegen das ERP feuert, gerät bei hohem Bestellaufkommen schneller an die Grenze als eine Anbindung, die Bestellungen gebündelt überträgt. Diese Limits werden also vor allem dann relevant, wenn viele Schnittstellen gleichzeitig aktiv sind oder ein einzelner Integrationspunkt hohe Frequenzen erzeugt. Bei der Konzeption einer Anbindung gehört die Frage nach dem zu erwartenden Aufrufvolumen deshalb von Anfang an auf den Tisch.

Job-Queues für die Hintergrundverarbeitung

Viele Aufgaben in einem ERP-System sollen nicht den Anwender blockieren, sondern im Hintergrund laufen: das Buchen großer Stapel, das Erzeugen von Berichten, der nächtliche Abgleich mit angebundenen Systemen, periodische Neuberechnungen. Dafür gibt es die Job-Queue – eine Warteschlange, in die solche Aufgaben eingestellt und von der Plattform zeitgesteuert oder ereignisgesteuert abgearbeitet werden. Auch die Job-Queue unterliegt einem Mengengerüst: Es gibt eine begrenzte Zahl an Verarbeitungseinheiten, die Aufgaben parallel abarbeiten können. Stellt man sehr viele schwergewichtige Jobs gleichzeitig ein, konkurrieren diese um dieselben Ressourcen und stauen sich auf.

In der Praxis heißt das, dass die Hintergrundverarbeitung bewusst geplant werden sollte: rechenintensive Läufe in lastarme Zeiten legen, lange Jobs aufteilen, statt einen einzigen Mammutlauf zu starten, und die zeitliche Staffelung so wählen, dass sich die Spitzen nicht überlagern. Gerade bei wachsendem Datenbestand wird dies relevant, weil Jobs, die anfangs in Sekunden durchliefen, mit zunehmender Datenmenge spürbar länger brauchen. Wer hier vorausschauend plant, vermeidet, dass sich Hintergrundprozesse gegenseitig blockieren und im schlimmsten Fall den interaktiven Betrieb ausbremsen.

Das Admin Center als Steuerzentrale

Die Verwaltung dieses gesamten Gerüsts erfolgt zentral über das Business Central Admin Center. Es ist die administrative Steuerzentrale, in der ein berechtigter Administrator die Umgebungen eines Tenants im Überblick hat und steuert. Hier werden neue Umgebungen angelegt und wieder entfernt, Sandboxes erzeugt und mit Produktivdaten befüllt, der Speicherverbrauch je Umgebung eingesehen und Update-Termine für die halbjährlichen Plattform-Releases verwaltet. Das Admin Center zeigt außerdem an, wie weit das Datenbankkontingent ausgeschöpft ist – eine Information, die für die vorausschauende Kapazitätsplanung unverzichtbar ist.

Diese zentrale, web-basierte Verwaltung ist einer der markantesten Unterschiede zur On-Premise-Welt. Dort oblag das Anlegen von Mandanten, das Einrichten von Servern und das Einspielen von Updates dem eigenen IT-Team oder einem Dienstleister mit direktem Zugriff auf die Serverinfrastruktur. Im Cloud-Modell ist diese Komplexität abstrahiert: Eine Umgebung entsteht per Klick, ein Update wird terminiert statt manuell installiert, und die darunterliegende Hardware bleibt vollständig unsichtbar. Diese Bequemlichkeit hat ihren Preis in Form der beschriebenen Grenzen – man tauscht uneingeschränkten Hardwarezugriff gegen einen bewirtschafteten, standardisierten Betrieb ein.

Ab wann werden Performance- und Speicherthemen relevant?

Die naheliegende Frage lautet: Ab welcher Größe muss man sich überhaupt Gedanken machen? Eine pauschale Schwelle gibt es nicht, aber es lassen sich klare Muster benennen. Solange ein Unternehmen mit einer überschaubaren Zahl an Benutzern und einem moderat wachsenden Datenbestand arbeitet, bewegt sich der Betrieb komfortabel innerhalb der vorgesehenen Grenzen, und das Mengengerüst spielt im Alltag praktisch keine Rolle. Relevant werden die Grenzen typischerweise an drei Punkten: wenn der Datenbestand über Jahre stark anwächst und das Datenbankkontingent ausreizt, wenn die Zahl gleichzeitiger Nutzer und paralleler Prozesse steigt und die Rechenleistung der Umgebung spürbar belastet, oder wenn intensive Integrationen ein hohes Volumen an Schnittstellenaufrufen erzeugen und an die API-Limits stoßen.

Der mit Abstand häufigste Auslöser ist der schlicht über die Zeit wachsende Datenbestand. Buchungsposten, Belege und Bewegungsdaten häufen sich Jahr für Jahr an, und was im ersten Betriebsjahr unproblematisch war, kann nach mehreren Jahren sowohl das Speicherkontingent als auch die Abfragegeschwindigkeit belasten – große Tabellen lassen sich langsamer durchsuchen und auswerten. Hier setzen vorausschauende Maßnahmen an: das gezielte Komprimieren oder Auslagern selten benötigter Altdaten, eine durchdachte Strategie für die Aufbewahrung historischer Bewegungen und eine regelmäßige Beobachtung des Speicherverbrauchs im Admin Center. Auch die Gestaltung von Auswertungen und Listen spielt hinein: Berichte, die ohne sinnvolle Eingrenzung über riesige Datenmengen laufen, werden mit dem Wachstum träge.

Für ein Unternehmen im Mittelstand ist die beruhigende Nachricht, dass die typischen Datenmengen eines mittelständischen Betriebs in aller Regel gut innerhalb der vorgesehenen Kontingente liegen und die Plattform für genau dieses Segment ausgelegt ist. Die Grenzen sind nicht dazu da, den normalen Betrieb einzuschränken, sondern um die geteilte Infrastruktur fair und stabil zu halten. Problematisch wird es vor allem dann, wenn ein Unternehmen ungewöhnlich datenintensive Prozesse fährt, sehr viele externe Systeme hochfrequent anbindet oder über Jahre keinerlei Datenpflege betreibt. In diesen Fällen lohnt sich eine frühzeitige Architekturberatung, damit das Mengengerüst zur tatsächlichen Last passt.

Der Unterschied zur On-Premise-Installation

Der Kontrast zum klassischen On-Premise-Betrieb der Navision-Vergangenheit zieht sich durch alle bisher beschriebenen Punkte und verdient eine zusammenfassende Betrachtung. Im eigenen Rechenzentrum war die Skalierung eine reine Hardware- und Lizenzfrage: Speicher, Arbeitsspeicher und Rechenkerne ließen sich nach Bedarf erweitern, die Zahl der Mandanten und Umgebungen war faktisch nur durch die Maschine und die eigene Verwaltungskapazität begrenzt, und Schnittstellen kannten kein plattformseitiges Throttling, weil das System niemandem sonst gehörte. Die Kehrseite: Sämtliche Verantwortung für Dimensionierung, Wartung, Updates und Verfügbarkeit lag beim Betreiber selbst, und Fehleinschätzungen bei der Hardware konnten teuer und langwierig sein.

In der Cloud kehrt sich dieses Verhältnis um. Der Plattformbetreiber übernimmt Infrastruktur, Wartung und die regelmäßigen Updates, und im Gegenzug gibt das Unternehmen die uneingeschränkte Kontrolle über die Ressourcen ab. An die Stelle frei erweiterbarer Hardware tritt ein klar definiertes, abgestuftes Mengengerüst aus Datenbankkontingent, Speicher-Zukauf, Sandbox-Anzahl, API-Limits und Job-Queue-Durchsatz. Das ist keine Schwäche, sondern eine andere Betriebslogik: weniger Freiheitsgrade, dafür planbare Standardisierung und entlastete eigene IT. Die folgende Gegenüberstellung fasst die zentralen Unterschiede in der Skalierungslogik zusammen.

Zusammengefasst ergibt sich ein stimmiges Bild: Die Cloud-Variante organisiert den Betrieb über die klar geschichtete Struktur aus Tenant, Umgebungen und Mandanten und setzt das Mengengerüst über ein bewirtschaftetes Kontingent an Speicher, Sandboxes, Schnittstellenkapazität und Hintergrunddurchsatz. Wer diese Struktur kennt und die wenigen relevanten Stellgrößen im Admin Center im Blick behält, kann das Wachstum seines Systems vorausschauend steuern und gerät selten unvorbereitet an eine Grenze. Wie sich die Software über Erweiterungen anpassen lässt, wie der Weg von alten Navision-Beständen in die aktuelle Software führt und wie eine Einführung methodisch abläuft, behandeln die übrigen Abschnitte dieser Seite. Wer die Skalierungsstruktur früh in die ERP-Auswahl einbezieht, trifft eine Entscheidung, die nicht nur zum heutigen, sondern auch zum künftigen Mengengerüst des Unternehmens passt.

Von Navision zur aktuellen Software: Migrationspfade und Datenübernahme

Viele Betriebe, die heute noch mit einem klassischen Navision-Stand oder einer älteren Version von Microsoft Dynamics NAV arbeiten, stehen früher oder später vor derselben Frage: Wie gelangen jahrelang gepflegte Stammdaten, offene Posten, individuelle Anpassungen und eingespielte Prozesse in die heutige Software-Generation, ohne dass dabei etwas verloren geht oder die laufende Arbeit zum Erliegen kommt? Die naheliegende Vorstellung – man exportiere den alten Stand und spiele ihn unmittelbar in die Cloud ein – trifft die technische Realität nicht. Zwischen einem in sich geschlossenen, lokal betriebenen NAV-Mandanten und einer modernen, mandantenfähigen Cloud-Umgebung liegen nicht nur Versionssprünge, sondern ein grundlegender Wandel der Plattformarchitektur, der Programmiersprache und des Betriebsmodells. Dieser Abschnitt beschreibt den technischen Weg in die aktuelle Software – also den eigentlichen Übergang – und grenzt sich damit bewusst von der Frage ab, wie die Software anschließend im Tagesgeschäft betrieben wird oder welche Edition für welchen Betrieb passt.

Der Begriff Migration wird im Umfeld dieser Produktfamilie oft unscharf verwendet. Gemeint sein kann das reine Übernehmen von Daten in eine bereits frisch eingerichtete Umgebung, ebenso aber das vollständige Anheben eines bestehenden Mandanten samt aller Anpassungen über mehrere Versionsstufen hinweg. Beides sind grundverschiedene Vorhaben mit unterschiedlichem Aufwand, unterschiedlichen Werkzeugen und unterschiedlichen Risiken. Wer den Übergang plant, muss diese Begriffe sauber trennen, weil davon abhängt, welcher Pfad überhaupt gangbar ist. Eine belastbare ERP-Lösung entsteht nicht dadurch, dass alte Bestände möglichst schnell irgendwohin kopiert werden, sondern dadurch, dass der Übergang als eigenständige technische Disziplin verstanden und in nachvollziehbare Stufen zerlegt wird.

Warum alte Stände nicht direkt in die Cloud springen

Der wichtigste Grund, warum ein alter Navision- oder NAV-Stand nicht in einem Schritt in die Cloud-Generation überführt werden kann, liegt in der Tiefe des technologischen Bruchs zwischen den Generationen. Ältere Versionen wurden in der herstellereigenen Sprache C/AL entwickelt, und Anpassungen wurden traditionell direkt in den Standardcode der Anwendung hineingeschrieben. Die heutige Cloud-Generation hingegen kennt diesen direkten Zugriff auf den Basiscode nicht mehr: Erweiterungen laufen ausschließlich in der modernen Sprache AL und liegen sauber getrennt vom Standard. Zwischen einem Mandanten, dessen Logik untrennbar mit individuell verändertem Standardcode verwoben ist, und einer Umgebung, die genau diese Vermischung nicht mehr zulässt, klafft eine Lücke, die kein einzelner Importvorgang überbrücken kann.

Hinzu kommt, dass die Datenstrukturen über die Versionen hinweg fortlaufend weiterentwickelt wurden. Tabellen wurden umbenannt, Felder neu zugeschnitten, Funktionsbereiche umgebaut. Ein Datenbestand aus einer mehrere Generationen zurückliegenden Version kann von der aktuellen Software nicht unmittelbar gelesen werden, weil ihr schlicht das Wissen über das alte Schema fehlt. Genau aus diesem Grund führt der saubere Weg über einen Zwischenschritt auf der lokal betriebenen Variante der aktuellen Produktgeneration: Dort wird der alte Stand zunächst auf das moderne Datenmodell angehoben, die Anpassungen werden in die neue Welt überführt, und erst dieser bereits modernisierte Stand bildet die Grundlage für den Schritt in die Cloud. Der Pfad lautet damit in seiner Grundform: vom alten Navision/NAV über die lokal installierte aktuelle Generation (On-Premise) und – wo gewünscht – über eine Hybrid-Phase hin zur vollständigen Cloud-Umgebung (Online).

Drei Vorhaben unterscheiden: Datenmigration, Hybrid-Betrieb und vollständiges Upgrade

Unter dem Sammelbegriff Migration verbergen sich drei deutlich verschiedene Szenarien, die zu trennen entscheidend ist, weil sie unterschiedliche Werkzeuge erfordern und unterschiedlich viel vom Alten bewahren.

Die reine Datenmigration verzichtet bewusst darauf, den alten Mandanten als technisches Gebilde zu übernehmen. Stattdessen wird eine frische, leere Umgebung der aktuellen Generation eingerichtet, und es werden ausschließlich die wirklich benötigten Daten – Stammdaten und ausgewählte Bewegungsdaten – in diese neue Struktur eingespeist. Alles, was sich über die Jahre angesammelt hat und nicht mehr gebraucht wird, bleibt zurück. Dieser Weg ist technisch der sauberste, weil die neue Umgebung ohne Altlasten startet; er verlangt aber, dass man die Daten aktiv aufbereitet und neu zuordnet, statt sie einfach zu übernehmen.

Der Hybrid-Betrieb beschreibt einen Übergangszustand, in dem der modernisierte lokale Stand und eine Cloud-Umgebung über einen gewissen Zeitraum parallel existieren. Die Produktivarbeit findet zunächst weiterhin lokal statt, während die Daten fortlaufend in die Cloud gespiegelt werden. Dieser Zustand ist kein Dauerziel, sondern eine kontrollierte Brücke: Er erlaubt es, die Cloud-Umgebung in Ruhe aufzubauen, zu testen und zu validieren, bevor die eigentliche Umschaltung erfolgt. Der Hybrid-Betrieb senkt das Risiko eines harten Stichtagswechsels, weil der alte Stand als Rückfallebene verfügbar bleibt, bis die neue Umgebung vollständig bestätigt ist.

Das vollständige Upgrade schließlich nimmt den bestehenden Mandanten samt seiner Anpassungen und hebt ihn über die notwendigen Versionsstufen hinweg auf den aktuellen Stand. Hier wird am meisten vom Alten bewahrt – einschließlich der individuell entwickelten Logik –, weshalb dieses Vorhaben zugleich das technisch anspruchsvollste ist. Es ist der typische Weg für Betriebe, deren über Jahre gewachsene Sonderprozesse zu wertvoll sind, um sie aufzugeben, und die deshalb den Aufwand der Überführung auf sich nehmen, statt auf der grünen Wiese neu zu beginnen. Welches der drei Vorhaben das richtige ist, ist eine der zentralen Weichenstellungen jeder ERP-Auswahl und hängt davon ab, wie viel des Bestehenden tatsächlich erhaltenswert ist.

Die Microsoft-Werkzeuge: Cloud Migration Tool und RapidStart

Für die beiden technisch unterschiedlichen Aufgaben – das fortlaufende Übernehmen großer Produktivdatenmengen einerseits und das strukturierte Einspielen aufbereiteter Stammdaten andererseits – stellt Microsoft zwei eigenständige Werkzeuge bereit, die nicht miteinander verwechselt werden sollten.

Das Cloud Migration Tool ist auf den Weg von der lokal installierten Generation in die Cloud-Umgebung zugeschnitten. Sein Zweck ist die laufende, wiederholbare Datenübernahme: Es stellt eine Verbindung zwischen dem On-Premise-Stand und der Cloud her und repliziert die Produktivdaten in die neue Umgebung. Entscheidend ist die Wiederholbarkeit – die Replikation kann mehrfach durchlaufen werden, sodass die Cloud-Umgebung über die gesamte Übergangsphase hinweg mit dem weiterlaufenden lokalen Betrieb synchron gehalten wird, bis der Zeitpunkt der endgültigen Umschaltung erreicht ist. Genau dieses Werkzeug macht den oben beschriebenen Hybrid-Betrieb praktisch möglich, weil es den Datenabgleich zwischen alter und neuer Welt übernimmt, ohne dass die Arbeit unterbrochen werden muss.

Die Configuration Packages, im Sprachgebrauch der Produktfamilie traditionell unter dem Namen RapidStart bekannt, verfolgen ein anderes Ziel. Sie dienen der Excel-basierten Übernahme von Stammdaten und der strukturierten Ersteinrichtung. Dabei werden definierte Tabellen als Vorlage in eine Tabellenkalkulation exportiert, dort befüllt oder bereinigt und anschließend wieder in die Umgebung eingelesen. Dieses Werkzeug ist das Mittel der Wahl, wenn Daten vor der Übernahme aufbereitet werden müssen – etwa weil sie aus einer Quelle stammen, die nicht der alte Mandant ist, oder weil Dubletten, veraltete Einträge und Inkonsistenzen ohnehin entfernt werden sollen. RapidStart eignet sich daher besonders für das Szenario der reinen Datenmigration in eine frische Umgebung sowie für nachträgliche Korrekturen und Ergänzungen von Stammdaten, auch nachdem der Betrieb bereits in der Cloud läuft.

Beide Werkzeuge schließen einander nicht aus, sondern ergänzen sich entlang des Migrationspfads. In einem vollständigen Upgrade mit anschließendem Cloud-Wechsel übernimmt das Cloud Migration Tool den Hauptbestand, während RapidStart einzelne Stammdatenbereiche ergänzt oder nachträglich bereinigt. In einer reinen Datenmigration trägt RapidStart die Hauptlast, während das Cloud Migration Tool keine Rolle spielt, weil es keinen anzuhebenden Altstand gibt.

Der Umgang mit C/AL-Altanpassungen: von der Modifikation zur Extension

Der technisch heikelste Teil jedes Übergangs sind die individuellen Altanpassungen. In älteren Navision- und NAV-Ständen wurde Sonderlogik typischerweise direkt in den Standardcode der Anwendung geschrieben – die eigene Anpassung und der herstellereigene Code waren untrennbar miteinander verwoben. Genau dieses Modell ist in der aktuellen Generation nicht mehr vorgesehen. Erweiterungen müssen heute als eigenständige, vom Standard getrennte AL-Extensions vorliegen. Die alten C/AL-Modifikationen lassen sich folglich nicht einfach mitnehmen; sie müssen in die neue Architektur überführt werden.

Dieser Schritt ist mehr als eine bloße Übersetzung von einer Sprache in die andere. Er zwingt dazu, jede einzelne Altanpassung zu hinterfragen: Wird diese Sonderlogik überhaupt noch gebraucht, oder bildet der heutige Standard die Anforderung inzwischen bereits ab? Funktionen, die in früheren Versionen individuell ergänzt werden mussten, sind über die Jahre vielfach in den Standardumfang eingeflossen. Eine ehrliche Bestandsaufnahme reduziert daher oft den Umfang der zu überführenden Anpassungen erheblich – und genau diese Reduktion ist einer der größten Gewinne des Übergangs, weil jede nicht mehr benötigte Sonderlogik künftige Updates erleichtert.

Was nach dieser Sichtung erhalten bleiben soll, wird als saubere AL-Extension neu aufgebaut, die sich an die vorgesehenen Erweiterungspunkte der Plattform hält, statt in den Standard einzugreifen. Damit verändert sich die Anpassung nicht nur technisch, sondern in ihrer gesamten Lebenslogik: Eine vom Standard getrennte Extension überlebt Plattform-Updates, weil sie den Basiscode nicht mehr berührt. Die Mühe der Überführung von C/AL nach AL ist deshalb keine reine Pflichtübung, sondern die eigentliche Voraussetzung dafür, dass die modernisierte Installation dauerhaft updatefähig bleibt. Wie diese Extensions anschließend bezogen, gepflegt und betrieben werden, ist Gegenstand der laufenden Betriebsbetrachtung und nicht dieses Übergangsschritts. Eine fachkundige Begleitung durch erfahrenes ERP-Consulting setzt genau an dieser Stelle an, weil die Entscheidung über jede einzelne Altanpassung sowohl technisches als auch prozessuales Urteilsvermögen verlangt.

Den Übergang als eigenständiges Vorhaben planen

Aus alldem folgt, dass der Weg von Navision in die aktuelle Software-Generation als eigenständiges technisches Vorhaben behandelt werden sollte – mit klar benannten Stufen, definierten Werkzeugen je Stufe und einer ehrlichen Inventur des Bestehenden. Am Anfang steht nicht die Frage, wie schnell man in die Cloud kommt, sondern die Frage, was vom alten Stand tatsächlich erhaltenswert ist: welche Daten gebraucht werden, welche Anpassungen noch eine Berechtigung haben und welche externen Schnittstellen weiterleben müssen. Erst diese Inventur entscheidet, ob eine reine Datenmigration genügt oder ob ein vollständiges Upgrade nötig ist, und sie bestimmt, wie groß der Aufwand der C/AL-zu-AL-Überführung ausfällt.

Die wiederholbare Natur des Cloud Migration Tools und die kontrollierte Hybrid-Phase sind die beiden Sicherheitsnetze, die den Übergang von einem riskanten Stichtagswechsel zu einem planbaren Vorgang machen. Sie erlauben es, die neue Umgebung aufzubauen, zu befüllen und ausgiebig zu prüfen, während der Altstand als Rückfallebene erhalten bleibt – und erst dann umzuschalten, wenn die neue Welt vollständig bestätigt ist. Wer den Übergang in dieser Reihenfolge angeht, überführt nicht nur Daten, sondern modernisiert seine gesamte Installation und legt damit das Fundament für ein zukunftsfähiges ERP-System, das mit jeder kommenden Plattformversion mitwachsen kann, statt erneut zum Sanierungsfall zu werden.

So führt man die Software ein: vom Standardprozess zum produktiven Einsatz

Eine moderne Business-Central-Umgebung wird heute nicht mehr in monatelanger Programmierarbeit aus dem Nichts errichtet, sondern in einem klar gestaffelten Adoptionsweg in Betrieb genommen, der mit funktionierenden Standardprozessen beginnt und sich von dort schrittweise an den eigenen Betrieb annähert. Dieser Abschnitt zeichnet genau diesen praktischen Einführungs- und Betriebsfluss nach – von der ersten Aktivierung der mitgelieferten Best-Practice-Prozesse über die assistierte Einrichtung und die behutsame Anpassung bis zum produktiven Go-Live und der dauerhaften Aufnahme der halbjährlichen Wave-Updates. Es geht hier ausdrücklich nicht darum, ob die Software die richtige Wahl ist oder an welchen Kriterien man sie misst; das ist Gegenstand einer eigenständigen Bewertung. Hier interessiert allein die Frage, wie der Weg vom ausgelieferten Standard zum produktiven, gepflegten System konkret verläuft – und welcher Aufwand dabei auf Anwender, Key-User und Partner entfällt.

Der entscheidende Perspektivwechsel gegenüber älteren Einführungsprojekten liegt darin, dass nicht mehr eine leere Datenbank am Anfang steht, in die man sich mühsam hineinarbeitet, sondern ein vollständig konfigurierter, lauffähiger Beispielmandant. Die Software bringt durchgängige Standardprozesse für Einkauf, Verkauf, Lager, Finanzbuchhaltung und Projektabwicklung bereits mit – inklusive Demodaten, an denen sich jeder Prozess von der Bestellung über den Wareneingang bis zur Rechnung durchspielen lässt. Die Einführung wird damit zu einer Bewegung des Konfigurierens und Reduzierens statt des Aufbauens: Man übernimmt, was passt, justiert, was abweicht, und ergänzt nur dort, wo der Standard die eigene Anforderung wirklich nicht trägt. Dieses Prinzip prägt jeden der folgenden Schritte.

Der Standard als Ausgangspunkt: Best-Practice-Demodaten

Am Anfang steht nicht das individuelle Modellieren, sondern das Erleben des Standards. Microsoft liefert mit der Software einen vorkonfigurierten Demonstrationsmandanten aus – im Sprachgebrauch der Produktfamilie traditionell als Cronus bekannt –, in dem sämtliche Kernprozesse mit realistischen Beispieldaten hinterlegt sind. Dieser Mandant ist weit mehr als eine Spielwiese: Er macht die im Produkt eingebauten Best Practices unmittelbar erfahrbar. Wer wissen will, wie ein Beschaffungsprozess, eine Lagerumbuchung oder ein Periodenabschluss im Standard ablaufen soll, spielt es schlicht durch, statt es zu erfinden. Genau dafür ist auch eine Navision-Demo gedacht: Sie zeigt den durchgängigen Soll-Ablauf, bevor irgendeine Anpassung erwogen wird.

Diese Reihenfolge ist mehr als didaktischer Komfort. Sie zwingt die spätere Einrichtung in eine gesunde Disziplin: Jede Abweichung vom durchgespielten Standard muss begründet werden. Was im Cronus-Mandanten bereits sauber funktioniert, sollte nicht ohne Not anders gebaut werden, weil jede Abweichung später gepflegt, getestet und durch die halbjährlichen Updates getragen werden muss. Der Aufwand in dieser ersten Phase entfällt fast vollständig auf die Key-User – also jene fachlich versierten Mitarbeiter aus den Abteilungen, die ihren Prozess kennen und ihn nun im Standard wiedererkennen oder bewusst davon abgrenzen. Der Partner steuert hier vor allem Wissen bei, welche Standardvariante zu welchem Geschäftsmodell passt; die normalen Anwender sind in dieser Phase noch kaum gefordert.

Einrichtung über Assisted Setup und Configuration Packages

Ist der gewünschte Soll-Ablauf am Standard verstanden, beginnt die eigentliche Einrichtung des produktiven Mandanten. Die Software führt sie über zwei sich ergänzende Mechanismen. Der erste ist der Assisted Setup: eine Sammlung geführter Einrichtungsassistenten, die zentrale Bereiche – die Firmenstammdaten, das Buchungsschema, die Nummernkreise, die Mehrwertsteuerlogik, die Anbindung an Office-Dienste – in einem dialoggeführten, abarbeitbaren Verfahren konfigurieren. Statt verstreute Einstellungsseiten von Hand zu suchen, folgt man einer kuratierten Liste von Aufgaben, die den Einrichtungsfortschritt sichtbar macht und sicherstellt, dass keine grundlegende Konfiguration vergessen wird.

Der zweite Mechanismus ist für die Übernahme strukturierter Daten und wiederkehrender Einrichtungswerte zuständig: die Configuration Packages, die in der Produktfamilie seit jeher unter dem Namen RapidStart geführt werden. Sie erlauben es, definierte Tabellen – etwa Sachkonten, Debitoren, Kreditoren, Artikel oder Buchungsgruppen – als Vorlage in eine Tabellenkalkulation zu exportieren, dort zu befüllen oder zu bereinigen und anschließend gesammelt wieder einzuspielen. Damit lässt sich eine konsistente Grundkonfiguration nicht nur einmal aufbauen, sondern als Paket konservieren und über mehrere Mandanten oder Umgebungen hinweg reproduzierbar wieder anwenden. Für eine im Mittelstand typische Einführung ist das ein wesentlicher Hebel: Die mühsame Handarbeit der Datenpflege wird zur kontrollierbaren, wiederholbaren Übung.

Eine bewährte Faustregel für diese Phase lautet: erst den Assisted Setup für die strukturellen Grundentscheidungen abarbeiten, dann mit Configuration Packages die Massendaten füllen. Wer die Reihenfolge umdreht und Stammdaten einspielt, bevor Buchungsschema und Nummernkreise stehen, riskiert Inkonsistenzen, die sich nur mit erheblichem Aufwand wieder bereinigen lassen.

Die Verantwortung verschiebt sich in dieser Phase. Den Assisted Setup begleitet typischerweise der Partner gemeinsam mit den Key-Usern, weil hier strukturelle Weichen mit Auswirkungen auf den gesamten späteren Betrieb gestellt werden. Die Befüllung der Configuration Packages dagegen ist überwiegend Key-User-Arbeit, oft unterstützt durch die Fachabteilungen, die ihre eigenen Stammdaten am besten kennen. Ein erfahrenes ERP-Consulting bringt an dieser Stelle vor allem den Blick dafür ein, welche Einstellungen sich später nur schwer ändern lassen und deshalb von Beginn an richtig gesetzt werden müssen.

Schrittweise Anpassung: Personalisierung und Extensions

Erst wenn der Standard eingerichtet und mit Daten gefüllt ist, beginnt die individuelle Annäherung – und auch sie folgt einer klaren Stufung vom Leichten zum Tiefgreifenden. Die unterste, aufwandärmste Stufe ist die Personalisierung. Jeder Anwender kann seine Arbeitsbereiche unmittelbar an seine Aufgaben anpassen: Felder ein- oder ausblenden, Spalten umsortieren, Kacheln verschieben, Listen filtern. Diese Anpassungen erfordern keine Entwicklung, keinen Partner und keinen Release-Zyklus – sie geschehen direkt in der Oberfläche und wirken sofort. Eine darüberliegende Stufe bilden die Konfigurationen durch Administratoren, mit denen sich Profile, Rollencenter und damit das Erscheinungsbild ganzer Benutzergruppen festlegen lassen, ohne dass Code im Spiel ist.

Reicht die reine Konfiguration nicht aus, weil echte Zusatzlogik, ein neues Feld in der Datenbank oder eine externe Anbindung gebraucht wird, kommt die nächste Stufe ins Spiel: die Extensions. Sie sind die einzig vorgesehene Form, die Software über den Standard hinaus zu erweitern, und liegen technisch sauber vom Basiscode getrennt. Ob eine solche Erweiterung als maßgeschneiderte, nur für den eigenen Mandanten gebaute Lösung oder als fertige Anwendung aus dem Marktplatz bezogen wird, ist eine eigene, weiterführende Frage, die an anderer Stelle dieser Seite behandelt wird; für den Einführungsfluss zählt allein das Prinzip, dass jede Anpassung als getrennte Erweiterung und nicht als Eingriff in den Standard erfolgt.

Dieses Prinzip ist der eigentliche Grund, warum die hier beschriebene Reihenfolge so wichtig ist: Personalisierung und Extensions überstehen die halbjährlichen Plattform-Updates, weil sie den Standard nicht berühren. Je disziplinierter eine Einführung beim Standard bleibt und je sauberer die wenigen wirklich nötigen Erweiterungen getrennt gehalten werden, desto reibungsärmer trägt das System die spätere Update-Kadenz. Die Aufwandsverteilung folgt der Stufung unmittelbar: Personalisierung ist Anwendersache, die administrative Konfiguration liegt bei den Key-Usern, und Extensions sind die Domäne des Partners oder eines internen Entwicklungsteams. Wer diese Verantwortlichkeiten von Beginn an klar zuordnet, vermeidet, dass triviale Wünsche zu Entwicklungsaufträgen aufgeblasen werden.

Pilot in der Sandbox, Go-Live in Production

Bevor der eingerichtete und angepasste Stand in den scharfen Betrieb geht, gehört er erprobt – und zwar in einer dafür vorgesehenen, vom Produktivsystem getrennten Umgebung. Die Software stellt hierfür Sandbox-Umgebungen bereit, die sich aus einer Kopie des Produktivmandanten oder aus den Demodaten erzeugen lassen. In dieser Sandbox spielen die Key-User die realen Geschäftsvorfälle durch: einen vollständigen Auftragsdurchlauf, einen Monatsabschluss, die kritischen Sonderfälle, die im Tagesgeschäft tatsächlich vorkommen. Hier zeigt sich, ob die Configuration Packages sauber gegriffen haben, ob die Extensions wie erwartet wirken und ob die personalisierten Oberflächen die Arbeit wirklich erleichtern.

Erst wenn der Pilot in der Sandbox abgenommen ist, erfolgt der Go-Live: Der freigegebene Stand wird in die Production-Umgebung übernommen, und der scharfe Betrieb beginnt. Dieser Übergang ist bewusst der schmalste Schritt des gesamten Wegs, weil alle inhaltliche Arbeit – Einrichtung, Anpassung, Erprobung – bereits davor geleistet wurde. Der Aufwand verschiebt sich am Go-Live spürbar: Vom Tag der Umschaltung an tragen die Anwender die Hauptlast, weil sie nun täglich mit dem System arbeiten, während Key-User und Partner in eine begleitende, unterstützende Rolle wechseln. Eine gute Einführung sorgt deshalb dafür, dass die Anwender den produktiven Stand bereits aus der Sandbox kennen und der Go-Live für sie keine Überraschung, sondern eine Bestätigung ist. Wie die Software dabei in eine durchgängige ERP-Lösung für den ganzen Betrieb übergeht, entscheidet sich maßgeblich an der Qualität dieser Pilotphase.

Die halbjährliche Update-Kadenz prägt den Dauerbetrieb

Mit dem Go-Live ist die Einführung nicht abgeschlossen, sondern geht in einen kontinuierlichen Betriebsrhythmus über, der die Software grundlegend von älteren Generationen unterscheidet. Microsoft veröffentlicht zweimal jährlich – in zwei sogenannten Release Waves – ein umfangreiches Funktionsupdate der Plattform. Diese Wave-Updates sind nicht optional: Die Umgebung wird zwangsläufig auf den aktuellen Stand geführt, wenn auch innerhalb eines steuerbaren Zeitfensters. Damit wird die Aktualisierung vom seltenen, riskanten Großprojekt zum planbaren Halbjahresrhythmus – ein fundamental anderer Betriebsmodus als das jahrelange Verharren auf einer eingefrorenen Altversion, wie es bei klassischen Installationen üblich war.

Praktisch bedeutet diese Kadenz, dass die oben gezeichneten Schritte drei und vier – Anpassung und Erprobung – nicht einmalig durchlaufen, sondern zyklisch wiederkehren. Vor jeder Wave wird das angekündigte Update zuerst in einer Sandbox eingespielt, dort werden die kritischen Prozesse und die eigenen Extensions gegen den neuen Stand geprüft, und erst nach erfolgreicher Abnahme wird die Production-Umgebung aktualisiert. Genau hierfür sind die getrennt gehaltenen Erweiterungen so wertvoll: Weil sie den Standard nicht berühren, ist das Risiko, dass eine Wave eine Anpassung bricht, gering und gut eingrenzbar. Je disziplinierter die Einführung beim Standard geblieben ist, desto leichtgewichtiger ist die wiederkehrende Update-Prüfung.

Die Update-Kadenz verteilt den Daueraufwand klar auf die Rollen. Die laufende Prüfung jeder Wave in der Sandbox liegt bei den Key-Usern, die ihre Prozesse kennen und Abweichungen früh erkennen; die technische Begleitung – das Einspielen, die Kontrolle der Extensions, das Lösen etwaiger Konflikte – obliegt dem Partner oder dem internen Team. Die Anwender bemerken im Idealfall vor allem das Ergebnis: neue Funktionen und Verbesserungen, die ohne Bruch in ihren gewohnten Arbeitsalltag einfließen. Dieser Rhythmus ist der Preis und zugleich der Gewinn der modernen Plattform – er verlangt eine dauerhaft eingespielte Pflegeroutine, hält das System aber fortwährend aktuell und verhindert, dass es über die Jahre erneut zum Sanierungsfall wird.

Der Aufwand über den gesamten Lebenszyklus

Fasst man den Weg vom Standard zum produktiven Dauerbetrieb zusammen, zeigt sich eine charakteristische Verschiebung der Last über die Phasen hinweg. Zu Beginn – beim Erleben des Standards und der strukturellen Einrichtung – tragen Key-User und Partner den Hauptanteil, während die Anwender kaum beteiligt sind. Mit Personalisierung und Pilotbetrieb rücken die Anwender und Key-User in den Vordergrund. Am Go-Live kippt das Gewicht endgültig zu den Anwendern, die das System nun täglich tragen. Und im Dauerbetrieb pendelt sich ein ruhiger, geteilter Rhythmus ein: Anwender personalisieren bei Bedarf selbst, Key-User prüfen die halbjährlichen Waves, der Partner begleitet technisch.

Diese Verteilung macht deutlich, dass die Einführung der Software kein einmaliger Kraftakt mit einem definierten Ende ist, sondern ein gestufter Prozess, der in einen pflegeleichten Dauerbetrieb mündet. Wer den hier gezeichneten Weg in der richtigen Reihenfolge geht – erst den Standard erleben, dann assistiert einrichten, behutsam anpassen, in der Sandbox erproben, kontrolliert in Produktion gehen und die Waves diszipliniert mitnehmen –, baut nicht nur ein lauffähiges, sondern ein dauerhaft tragfähiges ERP-System auf, dessen Betrieb mit jeder kommenden Plattformversion planbar mitwächst, statt von ihr überrascht zu werden.

Häufige Fragen