Wie lange dauert ein professioneller ERP-Auswahlprozess?

Realistische Spannen liegen bei drei bis sechs Monaten für Mittelständler und sechs bis zwölf Monaten für komplexe, internationale Konzernprojekte. Eine Verkürzung unter drei Monate geht fast immer zulasten der Qualität – insbesondere bei Lastenheft, Demos und Vertragsverhandlung.

Wann lohnt sich eine externe Auswahlbegleitung?

Externe Begleitung lohnt sich vor allem bei der ersten ERP-Einführung, bei internationalen Mehrländerprojekten und in stark regulierten Branchen. Die Investition zwischen 30.000 und 150.000 Euro amortisiert sich typischerweise über bessere Vertragskonditionen, geringere Customizing-Quoten und eine schnellere Time-to-Value.

Sollten wir uns auf einen Anbieter festlegen oder offen ausschreiben?

Eine offene Ausschreibung bringt fast immer bessere Konditionen und mehr Transparenz, auch wenn intern bereits ein Favorit existiert. Der Wettbewerbsdruck wirkt nachweislich preissenkend und führt zu schärferen Leistungsbeschreibungen. Eine Direktbeauftragung lohnt sich nur, wenn ein Konzernstandard zwingend ist oder der Markt extrem klein.

Wie viele Anbieter sollten in der Shortlist sein?

Drei bis maximal fünf. Weniger schwächt den Wettbewerb, mehr macht die Demos und die Bewertung unwirtschaftlich. Wichtig ist, dass die Kandidaten echte Alternativen sind und nicht nur Pflichtteilnehmer.

Von Microsoft Dynamics NAV auf Dynamics 365 Business Central wechseln

Microsoft Dynamics NAV (intern auch „Navision" genannt) war jahrzehntelang der Mittelstands-Standard im Microsoft-Stack. Mit der Cloud-Strategie von Microsoft wurde NAV in Dynamics 365 Business Central (BC) überführt. Mainstream-Support für klassische NAV-Versionen läuft schrittweise aus — die Migration auf BC ist für die meisten NAV-Anwender nicht mehr „ob", sondern „wann". Dieser Guide gibt einen praxisnahen Leitfaden.

Auslöser: Warum jetzt von NAV auf BC migrieren?

Mainstream-Support-Endes. Microsoft hat die Lifecycle-Termine für NAV-Versionen definiert. NAV 2018 war die letzte Hauptversion vor BC. Mainstream-Support für NAV 2018 lief Anfang 2023 aus, Extended-Support endet 2028. Wer auf älteren NAV-Versionen läuft (NAV 2016, 2017 oder früher), ist häufig schon out-of-support.

Kein Cloud-Pfad in NAV. NAV ist On-Prem-Architektur. Wenn dein Unternehmen Cloud-Modernisierung will, gibt es in NAV keinen Pfad — nur den Wechsel zu BC.

Fehlende moderne Funktionen. Power BI-Embedding, Power Automate-Workflows, AI-Insights, AppSource-Marketplace — alles BC-Features, die in NAV nicht verfügbar sind. Wer moderne Anwender-Erwartungen erfüllen will, braucht BC.

Stagnation der NAV-Customizing-Welt. ABAP-artige C/AL-Programmierung in NAV ist nicht mehr modern. BC's neue Programmiersprache AL plus Visual Studio Code, Git-Integration und moderne DevOps-Tools sind dramatisch besser.

Recruiting-Vorteil. Junge Microsoft-Entwickler kennen BC und AL — NAV-C/AL-Spezialisten werden seltener und teurer am Personalmarkt.

Wichtige Unterscheidung: Welche NAV-Version habt ihr?

Der Migrations-Pfad hängt stark von eurer aktuellen NAV-Version ab.

NAV 2013 oder älter. Der größte Sprung. Direkter Upgrade-Pfad zu BC ist nicht möglich — entweder mehrstufiger Upgrade über NAV 2017/2018 zu BC, oder direkte Re-Implementation als BC-Greenfield.

NAV 2015–2017. Direkter In-Place-Upgrade über offizielle Microsoft-Tools möglich, aber komplex. Custom-Code wird automatisch migriert, manueller Nacharbeit-Aufwand erheblich.

NAV 2018. Beste Ausgangslage. Direkter Upgrade-Pfad zu BC ist gut dokumentiert, viele Custom-Objekte werden automatisch in BC-Erweiterungen (AL) konvertiert.

Cloud-Versionen NAV 2018 / BC On-Prem. Bereits sehr nah an Cloud-BC. Wechsel auf BC SaaS ist eher technische Migration als Architektur-Umbau.

Drei Migrations-Strategien

1. Technical Upgrade (In-Place)

NAV-Datenbank wird mit Microsoft-Tools schrittweise auf BC migriert. C/AL-Code wird in AL-Erweiterungen konvertiert. Datenmodell wird angepasst. Anwender bekommen neue UI, aber funktional läuft alles ähnlich weiter.

Vorteil: schnellster Pfad, geringster Schulungs-Aufwand. Nachteil: technische Schulden werden mitgeschleppt, Custom-Code-Modernisierung wird verschoben.

2. Re-Implementation (Greenfield)

Neue BC-Cloud-Instanz aufsetzen, Stammdaten neu importieren, Konfiguration nach BC-Best-Practices machen, Custom-Logik nur dort als AL-Erweiterung re-implementieren wo zwingend nötig.

Vorteil: saubere BC-Cloud-Architektur, keine Altlasten, Modernisierungs-Hebel groß. Nachteil: längerer Projektzeitraum, höherer Schulungs-Aufwand, Datenmigrations-Aufwand.

3. Hybrid

NAV-Datenbank wird teilweise migriert (Stammdaten, kritische Custom-Objekte), Standard-Konfiguration nach BC-Best-Practices neu gemacht. Mischform.

Vorteil: balanced — saubere Modernisierung mit Datenkontinuität. Nachteil: aufwendigste Projekt-Steuerung.

Migrations-Phasen — typischer Ablauf

Phase 1 — Discover (3–6 Wochen). NAV-Bestandsaufnahme: Version, Datenbank-Größe, Custom-Code-Volumen (Anzahl C/AL-Objekte), Add-ons (NAV-Branchen-Lösungen wie LS Retail, To-Increase, NAV4Construction etc.). BC-Demo. Strategie-Entscheidung Technical Upgrade / Greenfield / Hybrid.

Phase 2 — Prepare (4–8 Wochen). BC-Tenant einrichten. Lizenz-Modell festlegen (Essentials/Premium, User-Anzahl). Implementierungs-Partner aussuchen (zertifizierter Microsoft-BC-Partner mit NAV-Migrations-Erfahrung). Custom-Code-Inventur (Code-Analyse mit Tools wie Code Analyzer for AL).

Phase 3 — Migrate Code (8–24 Wochen, hoch-variable). Bei Technical Upgrade: C/AL-Objekte automatisiert in AL-Erweiterungen konvertieren. Manuelle Nacharbeit: Code-Modernisierung, BC-spezifische API-Calls, Performance-Optimierungen. Bei Greenfield: keine Code-Migration, Custom-Logik wird in AL neu implementiert wo nötig.

Phase 4 — Migrate Data (4–10 Wochen). Stammdaten extrahieren, bereinigen, in BC importieren. Bewegungsdaten-Strategie: vollständig (bei Technical Upgrade) oder offene Posten + 2–3 Jahre Historie (Greenfield).

Phase 5 — Test (4–8 Wochen). UAT, Integration-Tests mit Schnittstellen-Systemen (DATEV, Bank, Lager etc.), Performance-Tests, Schulungs-Vorbereitung.

Phase 6 — Cutover & Stabilize (2–6 Wochen). Final-Cutover am Wochenende. NAV wird Read-Only. BC produktiv. Hypercare-Phase.

Insgesamt: 6–12 Monate für typische NAV-Upgrades, 9–18 Monate bei größeren Re-Implementations.

Custom-Code: Der Knackpunkt jeder NAV-Migration

Der Custom-Code-Anteil ist der größte Risiko-Faktor. NAV-Anwender haben über die Jahre oft Hunderte oder Tausende C/AL-Objekte angesammelt: Custom-Tabellen, Formulare, Reports, Codeunits. Bei der BC-Migration müssen diese in AL-Erweiterungen konvertiert werden.

Tooling. Microsoft bietet automatische Konvertierung (txt2al-Tool). Die Konvertierung ist meist 70–85% automatisch erfolgreich — der Rest ist manuelle Nacharbeit. Ältere C/AL-Patterns (z.B. Form-basierte Logik) müssen in BC-Standard-Patterns überführt werden.

Tiefe der Anpassung. Bei sehr customized NAV-Setups (>500 Custom-Objekte) ist Greenfield-Re-Implementation oft schneller als Technical Upgrade — weil man nicht 100% Custom-Code retten muss.

Branchen-Add-ons. Wenn NAV-Branchen-Add-ons (z.B. LS Retail) im Einsatz sind: prüfen, ob Hersteller eine BC-Version anbietet. LS Retail, KUMAVISION und To-Increase haben BC-Pendants — andere kleinere Branchen-Add-on-Hersteller manchmal nicht.

Custom-Reports. NAV-Reports (RDLC, Word-Layouts) funktionieren mit Anpassungen in BC. Übernahme ist möglich, aber Nacharbeit erforderlich.

Datenmigration

Stammdaten. Item, Customer, Vendor, G/L Account, Cost Center sind im Datenmodell weitgehend kompatibel zwischen NAV und BC — Standard-Tools migrieren das robust.

Bewegungsdaten. Bei Technical Upgrade vollständig übernommen. Bei Greenfield: empfohlene Strategie ist „offene Posten zum Stichtag + 2 Jahre Historie für Reporting-Vergleichbarkeit". Ältere Historie kann in BC-Archive-Tabellen oder als separate Read-Only-NAV-Instanz weiter zugänglich gehalten werden.

Custom-Daten. Wenn NAV Custom-Tabellen mit unternehmenskritischen Daten hat (z.B. Anlagenakte, Wartungs-Historie), müssen diese in entsprechende BC-AL-Erweiterungs-Tabellen übernommen werden. Mapping-Aufwand kann erheblich sein.

Aufwand & Kosten

Größe	Custom-Tiefe	Zeitrahmen	Gesamtkosten-Range
Klein (10–50 MA)	Standard-NAV	4–7 Monate	100.000 – 280.000 EUR
Mittel (50–150 MA)	Mittlere Customizing	6–12 Monate	250.000 – 700.000 EUR
Mittel-Groß (150–500 MA)	Tiefe Customizing	9–18 Monate	600.000 – 1.800.000 EUR
Komplex (Multi-Country, viele Add-ons)	Hohe Customizing	12–24 Monate	1.500.000 – 4.000.000 EUR

BC-Lizenz-Kosten: Essentials ca. 70 EUR/User/Monat, Premium ca. 100 EUR/User/Monat. Bei 100 Usern Premium: 120.000 EUR/Jahr Lizenz.

Stolperfallen

C/AL-Code-Konvertierung unterschätzt. Viele NAV-Anwender denken „Tool macht alles automatisch". Realität: 15–30% der Code-Konvertierung ist manuelle Nacharbeit. Plan: Code-Analyse VOR dem Projekt-Kick-off.

Branchen-Add-ons ohne BC-Pendant. Wenn ein NAV-Branchen-Add-on im Einsatz ist, das BC nicht unterstützt, kann die Migration scheitern. Prüfe Add-on-Hersteller-Roadmap frühzeitig.

Custom-Reports vergessen. Reports sind oft business-kritisch. Eine vollständige Report-Inventur in Phase 1 ist Pflicht.

Stammdaten-Qualität nicht bereinigt. Wer schlechte NAV-Daten direkt nach BC migriert, hat schlechte BC-Daten. Bereinigung ist nicht „nice to have", sondern Voraussetzung.

Schnittstellen-Inventar unvollständig. NAV ist oft tief in Drittsysteme eingebunden. DATEV, Bank, Lager, Versand, BI — alle müssen für BC neu eingerichtet werden.

Performance-Thema in Cloud-BC. BC SaaS hat begrenzte Customizing-Optionen (kein direkter Datenbank-Zugriff). Performance-Bottlenecks im NAV-Custom-Code, die durch direkte SQL-Queries gelöst wurden, müssen in BC anders angegangen werden (oft via Power BI oder Azure Data Lake).

Hypercare-Aufwand vergessen. Anwender haben Jahre mit NAV-UI gearbeitet. BC ist anders. Hypercare-Phase 4–8 Wochen mit erhöhter Beratungs-Verfügbarkeit.

Erfolgsfaktoren

Microsoft-Partner mit dokumentierter NAV-zu-BC-Migrations-Erfahrung. Frage nach abgeschlossenen Migrationen in deiner Größe und Branche.

Frühe Code-Analyse. Lass den Custom-Code mit Tools auswerten BEVOR du das Projekt freigibst. Erkennt unerwartete Komplexität.

Phased Cutover bei großen Setups. Bei Multi-Country: nicht alle Töchter gleichzeitig migrieren. Pilot-Tochter zuerst, Lessons Learned, dann Roll-out.

Power Platform früh nutzen. BC's Power-Automate- und Power-Apps-Integration ist mächtig. Wer früh in dieser Richtung denkt, modernisiert nicht nur das ERP, sondern den ganzen Workflow-Stack.

Anwender-Ambassadoren. Pro Fachbereich 1–2 erfahrene NAV-Anwender als BC-Pioniere ausbilden. Sie helfen Kollegen während Hypercare.

Wann sich der Wechsel NICHT lohnt

Geplante Veräußerung kurzfristig. Käufer wird ohnehin auf seine ERP-Plattform migrieren wollen.

Sehr starkes proprietäres NAV-Branchen-Add-on ohne BC-Pendant. Selten, aber kommt vor. Dann oft entweder beim NAV-Anbieter bleiben (Extended Support nutzen) oder strategischer Re-Plattform-Wechsel zu einer Branchen-spezifischen Alternative.

Sehr kleine NAV-Setups (5–10 User) mit minimaler Nutzung. Ggf. ist der Wechsel zu einer KMU-Lösung wie Sage 50 oder Lexware wirtschaftlicher als BC.

In allen anderen Fällen ist BC der natürliche Nachfolger — und je früher der Wechsel passiert, desto weniger NAV-Custom-Schulden müssen mitgenommen werden.

FAQ

Wann ist NAV out-of-support? NAV 2018 Mainstream-Support endete Anfang 2023, Extended Support endet 2028. Ältere NAV-Versionen sind bereits out-of-support oder bald.

Können wir auf BC On-Prem (statt Cloud) migrieren? Ja, BC ist auch On-Prem verfügbar. Aber Microsoft investiert primär in Cloud-Versionen — neue Funktionen kommen zuerst Cloud-only. Empfehlung: Cloud, sofern keine spezifische Compliance-Anforderung dagegen spricht.

Wie lang dauert die durchschnittliche NAV-zu-BC-Migration? 6–12 Monate für Mittelstand-Setups mit moderater Customizing-Tiefe. Bei umfangreicher Customizing oder Multi-Country: 12–24 Monate.

Welche Microsoft-Tools helfen bei der Migration? txt2al für Code-Konvertierung, BC Cloud Migration Tool für Daten-Migration, Visual Studio Code mit AL-Extension für Entwicklung, Code Analyzer für AL für Code-Qualitäts-Analyse.

Können wir während der Migration weiter mit NAV produktiv arbeiten? Ja, das Projekt läuft parallel. Aber: NAV-Code-Änderungen während der Migrations-Phase müssen synchronisiert werden — Empfehlung: Code-Freeze in NAV während der finalen Phasen.

Was passiert mit unseren NAV-Reports? RDLC-Reports laufen in BC mit Anpassungen. Word-Layouts ebenfalls. Klassische Form-basierte Reports müssen neu gebaut werden — meist mit Word-Layouts oder Power BI.

Werden unsere Drittanbieter-Add-ons unterstützt? Hängt vom Hersteller ab. LS Retail, KUMAVISION, To-Increase, prodware: ja. Kleinere/lokale Add-ons: prüfen.