Business Central im Mittelstand — wann die Microsoft-Lösung trägt und wo ihre Grenzen liegen.

Wo Business Central im Markt steht

Business Central ist Microsofts ERP für den Mittelstand — hervorgegangen aus Dynamics NAV („Navision"), heute als Cloud-first-Produkt mit zwei großen Release-Waves pro Jahr weiterentwickelt. Im DACH-Raum trifft es auf eine der dichtesten Partnerlandschaften überhaupt und auf zehntausende Bestandsinstallationen aus NAV-Zeiten. Das macht es in Auswahlprojekten fast immer zum Referenzpunkt: Selbst wer sich am Ende anders entscheidet, vergleicht meist gegen Business Central.

Diese Allgegenwart ist Stärke und Risiko zugleich. Stärke, weil Erfahrung, Erweiterungen und Personal breit verfügbar sind. Risiko, weil „nehmen wir halt Microsoft" eine Architekturentscheidung durch eine Gewohnheitsentscheidung ersetzt. Die Einordnung auf unserer Business-Central-Profilseite liefert die Kurzfassung; dieser Beitrag geht in die Entscheidungslogik.

Für wen Business Central typischerweise passt

Aus Auswahlprojekten ergibt sich ein klares Fit-Profil. Größe: klassischer Mittelstand von etwa 20 bis 500 Mitarbeitenden — Einzelgesellschaften und kleinere Gruppen mit überschaubaren Prozessvarianten und Standardnähe. Branchen: besonders belastbar in Handel und Distribution, Projektdienstleistung, Service und Montage sowie leichter Fertigung; für Variantenfertigung oder tiefe MES-Anbindung sind in der Regel Add-ons oder Branchenlösungen nötig. IT-Landschaft: Unternehmen, die bereits mit Microsoft 365, Teams und Power BI arbeiten, profitieren vom durchgängigen Identitäts-, Berechtigungs- und Reporting-Stack.

Ebenso klar ist das Gegenprofil: Konzernstrukturen mit Multi-GAAP-Konsolidierung, großvolumige internationale Rollouts und schwere Fertigung sind nicht der Kern von Business Central — dafür stehen Dynamics 365 Finance & Operations, SAP S/4HANA oder, für Multi-Entity-Cloud-Setups, Oracle NetSuite auf der Prüfliste. Wie man solche Strukturen bewertet, zeigt der Beitrag zur ERP-Auswahl bei Multi-Entity-Strukturen.

Editionen und Lizenzlogik verstehen

Business Central kennt zwei Hauptausprägungen der Nutzerlizenz: Essentials deckt Finanzen, Einkauf, Verkauf, Lager, Projekte und CRM-Grundfunktionen ab; Premium ergänzt Fertigung (Produktionsaufträge, Arbeitspläne) und Servicemanagement. Dazu kommen Team-Member-Lizenzen für Gelegenheitsnutzer mit stark eingeschränkten Rechten — in der Praxis der wichtigste Hebel, um die Lizenzkosten realistisch zu halten.

Zwei Regeln haben sich bewährt. Erstens: Die Edition wird pro Umgebung gewählt, nicht pro Nutzer — wer Fertigung braucht, lizenziert alle vollwertigen Nutzer als Premium; das gehört früh in die Kalkulation. Zweitens: Rollen vor Lizenzen. Erst wenn je Rolle klar ist, wer wirklich bucht, plant und rückmeldet — und wer nur freigibt oder einsieht —, lässt sich der Mix aus Voll- und Team-Member-Lizenzen seriös rechnen. Konkrete Preise gehören nicht in diesen Beitrag: Sie ändern sich, sind verhandelbar und stehen in der jeweils aktuellen Microsoft-Preisliste — in der Auswahl zählt die Struktur, nicht der Listenpreis.

Das Microsoft-Ökosystem als Argument — und als Falle

Das stärkste Argument für Business Central steht selten in der Funktionsliste: Es ist die Umgebung. Excel-Integration in beide Richtungen, Outlook-Belegbearbeitung, Teams-Freigaben, Power BI als Reporting-Standard, Power Automate für Genehmigungs-Workflows, AppSource als Marktplatz für Branchen-Erweiterungen — vom DATEV-Anschluss bis zur Lagersteuerung. Wer diese Bausteine ohnehin nutzt, bekommt Integrationsleistung geschenkt, die bei anderen Systemen Projektaufwand wäre. Wie das Zusammenspiel architektonisch aussieht, beschreibt der Beitrag ERP im Microsoft-Ökosystem.

Die Falle: Das Ökosystem-Argument ersetzt keine Prozessprüfung. Ein Unternehmen mit komplexer Variantenfertigung wird nicht dadurch glücklich, dass die Rückstandsliste in Teams geteilt werden kann. In der Demo gehören deshalb die eigenen Kernprozesse auf den Tisch — mit eigenem Mengengerüst, wie im Leitfaden zum Auswahlprozess beschrieben, nicht die Standard-Präsentation der Office-Integration.

NAV-Migration: ein eigener Projekttyp

Ein großer Teil der Business-Central-Projekte im DACH-Raum sind keine Neuauswahlen, sondern Ablösungen alter Dynamics-NAV-Stände. Wichtig ist die richtige Erwartung: Das ist kein Update, sondern ein Migrationsprojekt mit eigenen Regeln. Anpassungen aus der C/AL-Ära existieren im Cloud-Modell nicht weiter — sie müssen als Extensions neu gebaut oder, besser, gegen den heutigen Standard geprüft und oft ersatzlos gestrichen werden. Erfahrungsgemäß erweist sich ein erheblicher Teil historischer Anpassungen als überflüssig, weil der Standard die Anforderung inzwischen abdeckt.

Für die Auswahlentscheidung heißt das: Eine NAV-Migration gehört wie eine Neueinführung behandelt — mit Prozessaufnahme, Muss-Kriterien und Partnervergleich. Der „Heimspieler"-Partner, der das alte NAV betreut hat, gehört in den Vergleich, aber nicht ungeprüft gesetzt. Und wer ohnehin neu bewertet, sollte den Markt einmal strukturiert sichten: Manchmal bestätigt die Auswahl Business Central, manchmal zeigt sie, dass die Anforderungen inzwischen woanders besser aufgehoben sind.

Projektrealität: Partner, Extensions, Release-Waves

Partnerqualität streut stark. Die Partnerdichte ist ein Vorteil, macht die Auswahl aber anspruchsvoller: Zertifikate und Logos sagen wenig über Projekt-Seniorität in Ihrer Branche. Benannte Schlüsselpersonen, Referenzen im vergleichbaren Prozessumfeld und eine ehrliche Auskunft zur Teamauslastung sind die belastbareren Signale — Partnerwahl und Systemwahl sind zwei getrennte Entscheidungen.

Extensions-Disziplin entscheidet über die Update-Fähigkeit. Anpassungen laufen heute als saubere Erweiterungen neben dem Standard. Wer diese Disziplin hält, nimmt die zwei jährlichen Release-Waves ohne Drama mit; wer sie aufweicht, baut technische Schulden auf, die sich bei jedem Update verzinsen. In den Vertrag gehört deshalb eine klare Regel, wie Erweiterungen gebaut, dokumentiert und über Releases getragen werden — und im Betrieb ein fester Prozess, der jede Wave in einer Sandbox prüft, bevor sie produktiv wird.

Grenzen: wann etwas anderes besser passt

Drei Konstellationen sprechen regelmäßig gegen Business Central als Kernsystem. Erstens komplexe Fertigung: mehrstufige Variantenkonfiguration, enge MES-Kopplung und Werkstattsteuerung in der Tiefe sind Add-on-Territorium — hier muss der konkrete Branchen-Stack verprobt werden, nicht das Basisprodukt. Zweitens Konzern-Finance: Multi-GAAP, komplexe Konsolidierung und großvolumige internationale Strukturen gehören zu Finance & Operations, SAP oder NetSuite — siehe Konzernkonsolidierung im Mittelstand. Drittens Nicht-Microsoft-Landschaften: Wer bewusst außerhalb des Microsoft-Stacks arbeitet, verliert das zentrale Integrationsargument und sollte Alternativen wie Odoo, Weclapp oder branchenspezifische Systeme gleichwertig prüfen — einen Einstieg gibt die Übersicht der ERP-Lösungen.

Kostenlogik

Für die Budgetplanung gelten die üblichen Regeln: Lizenzen sind nur ein Teil der Gesamtkosten; Implementierung, Datenmigration, Integrationen, Schulung und interner Aufwand tragen den größeren Anteil. Als Orientierungsrahmen aus Auswahlprojekten bewegen sich Business-Central-Einführungen im kleinen Mittelstand im unteren sechsstelligen Bereich (Jahr 1), mit Prozessvarianten und Integrationen im mittleren sechsstelligen Bereich, Gruppen-Setups mit Template und Rollout darüber. Die vollständige Kostensystematik — inklusive der häufig vergessenen Posten wie Weiterentwicklung nach Go-Live — steht im Beitrag ERP-Kosten realistisch einordnen.

Acht Prüffragen vor der Entscheidung

1. Welche unserer Kernprozesse laufen im Standard, welche brauchen AppSource-Add-ons — und was kosten diese Add-ons über fünf Jahre?
2. Essentials oder Premium: Welche Rollen erzwingen die Edition, und wie viele Nutzer sind ehrlich gerechnet Team Members?
3. Wie sieht unser Rollen-/Lizenzmix konkret aus — wer bucht, wer meldet zurück, wer sieht nur ein?
4. Bei NAV-Erbe: Welche Alt-Anpassungen deckt der heutige Standard ab, welche werden als Extension neu gebaut, welche entfallen?
5. Wie viele Projekte unserer Größe und Branche hat der Partner live gebracht — mit welchen benannten Personen für unser Projekt?
6. Wie ist der Release-Prozess organisiert: Wer testet die zwei jährlichen Waves, in welcher Sandbox, mit welchem Rückfallplan?
7. Welche Integrationen (DATEV, Shop, Logistik, PDM/PLM) sind Standard, welche Partnerleistung — und wer betreibt sie dauerhaft?
8. Was ist unser Exit-Szenario: Datenexport, Vertragslaufzeiten, Abhängigkeit von partner­spezifischen Erweiterungen?

Diese Fragen lassen sich direkt in ein Demo-Skript übersetzen — das Vorgehen dazu steht im ERP-Auswahlprozess in sechs Phasen. Für eine erste Standortbestimmung Ihres Profils liefert der ERP-Fit-Check eine Ersteinordnung ohne Kontaktzwang.

Häufige Fragen zu Business Central im Mittelstand

Ist Business Central der Nachfolger von Dynamics NAV / Navision?

Ja. Business Central ist die Weiterentwicklung von Dynamics NAV als Cloud-first-Produkt. Für bestehende NAV-Installationen ist der Wechsel allerdings kein Update, sondern ein eigenständiges Migrationsprojekt: Anpassungen aus C/AL-Zeiten müssen als Extensions neu aufgebaut, Daten migriert und Prozesse gegen den heutigen Standard geprüft werden.

Für welche Unternehmensgröße passt Business Central typischerweise?

Der Kern liegt im klassischen Mittelstand von etwa 20 bis 500 Mitarbeitenden — Einzelgesellschaften und kleinere Gruppen mit standardnahen Prozessen. Darunter ist BC oft überdimensioniert, darüber bzw. bei komplexen Konzernstrukturen wird Dynamics 365 Finance & Operations oder eine andere Konzernlösung geprüft.

Braucht Business Central zwingend das Microsoft-Ökosystem?

Nein, aber dort spielt es seine Stärken aus: Identitäten, Teams, Outlook, Excel und Power BI greifen ab Werk ineinander. Wer ohne Microsoft 365 arbeitet, verliert einen wesentlichen Teil des Arguments und sollte Alternativen gleichwertig prüfen.

Was kostet ein Business-Central-Projekt?

Als Orientierungsrahmen aus Auswahlprojekten: kleiner Mittelstand ab unterem sechsstelligen Bereich im ersten Jahr, mit Prozessvarianten und Integrationen mittlerer sechsstelliger Bereich, Gruppen-Rollouts darüber. Entscheidend ist die TCO-Betrachtung über fünf Jahre — Lizenzen sind nur ein Teil. Details im Beitrag zu ERP-Kosten.

Woran scheitern Business-Central-Projekte am häufigsten?

Selten am Produkt, häufig an der Partnerwahl und an fehlender Extensions-Disziplin: zu viele Anpassungen außerhalb des Standards, ignorierte Release-Waves und ein Implementierungsteam ohne Branchenerfahrung. Die Prüffragen in diesem Beitrag setzen genau dort an.

Autor: Joerg H. Paul Schaefer · Stand: September 2026 · Einordnung auf Basis dokumentierter Auswahlprojekte; Produktdetails bitte stets gegen die aktuelle Microsoft-Dokumentation prüfen. erp-check.info ist eine herstellerunabhängige Informationsplattform.