Die Besten Upgrademöglichkeiten zu Business Central 2025

2025 ist kein Jahr für halbe Sachen. Seit v26 (2025 Wave 1) gilt für viele Szenarien ein klarer, stufenweiser Pfad: Für die Cloud‑Migration muss Ihre On‑Prem‑Lösung mindestens auf v25 gebracht werden; Außerdem ist v26 ein Stepping‑stone‑Release, d. h. direkte Sprünge über mehrere Hauptversionen sind eingeschränkt. Das beeinflusst Budget, Downtime und Tool‑Auswahl – und zwar spürbar.

Diese Möglichkeiten haben Sie beim Upgrade.

1) Greenfield / „Grüne Wiese“

Nur wichtige Stammdaten (Debitoren, Kreditoren, Artikel, ggf. offene Salden) plus neue Prozesse/Customizing in Business Central.

Vorteile: Schlank, schnell, weniger Altlasten.

Nachteile: Historie bleibt im Altsystem/Archiv; zusätzliche Aufwände für Reporting über Alt‑ und Neusystem hinweg.

2) Komplette Datenübernahme

Volle Historie (Stammdaten und Bewegungsdaten) wechselt nach Business Central.

Vorteile: Ein System, vollständige Auskunftsfähigkeit.

Nachteile: Technisch komplexer, höhere Datenmenge und somit typischerweise längere Umschaltfenster, mehr Tests.

Die Optionen im Überblick

Hinweis: Warum „Einbahnstraße“ beim Standardpfad? Beim Microsoft‑Datenupgrade werden alle Clients getrennt; nach erfolgreichem Datenupgrade ist erneute Replikation aus der Altversion nicht zulässig (Risiko Datenkorruption). Das ist technisch bedingt und gilt unabhängig davon, welcher Dienstleister das Upgrade fährt.

Stärken & Schwächen im Detail

Konfigurationspakete (ehem. „RapidStart“)

Pro:

• An Bord, kostengünstig, schnell für Stammdaten (Kunden, Lieferanten, Artikel, G/L‑Grundeinrichtung).
• Seit 2024/25: BLOB-/Mehrzeilen‑Text kann via Paket verarbeitet werden (Base64).

Contra:

• Nicht für bestehende produktive Firmen gedacht; große Importe können die Nutzung blockieren – für Massenimporte XMLports.
• Kein Livesync, keine Historien‑Konvertierung (nur Import), Test/Fehlersuche oft manuell.
• Keine Postenübernahme oder gebuchte / ungebuchte Belege (z.B. Rechnungen) möglich
• Bei großen Datenmengen sehr langsam
• Konfigurationspakete müssen in der richtigen Reihenfolge eingespielt werden, sonst gibt es Validierungsfehler (bei Verknüpfungen zwischen Tabellen)

Fazit: Ideal für „Grüne Wiese“. Für komplette Datenübernahme (inkl. gebuchter Posten und Belege) ungeeignet bzw. aufwändig und langsam.

DataMigrate Pro(IO Integrated)

Pro:

• Direktmigration aus sehr alten Navision/NAV‑Versionen ohne „Jump‑Versionen“
• Bidirektionale Live‑Synchronisation (NAV↔BC), Delta‑Loads, Parallelbetrieb – dadurch minimale / keine Downtime und planbarer Cutover.
• Ziel Cloud oder On‑Prem; eignet sich für Greenfield (Teilmenge) und komplette Übernahme.

Contra:

• Umfangreiche Features die überwiegend über ein Kommandozeilentool funktionieren. Erfordert unter Umständen eine kurze Unterweisung in der Nutzung.

Fazit: Technisch attraktiv, wenn Downtime minimiert und Althistorie vollumfänglich übernommen werden soll.

Dienstleister auf Microsoft-Standardpfad

Pro:

• Nutzung des Standard-Upgradepfads

Contra:

• Cutover‑Downtime ist systemimmanent: Beim Datenupgrade werden alle Verbindungen getrennt; danach ist Replikation nicht mehr erlaubt – Einbahnstraße.
• Für BC Online / SaaS muss das OnPrem‑System mindestens v25 haben -> ggf. zusätzliche Zwischenschritte.
• Teuerste Lösung (i.d.R. zwischen 50.000 und 150.000 EUR)

Fazit: Wenn eine lange Downtime und hohe Kosten kein Problem darstellen, dann stellt dieser weg eine akzeptable Lösung dar.

Spezifika, die Sie nicht ignorieren sollten

• Cloud‑Migration nur ab v25 – Vor dem Umzug in die Cloud ist eine Aktualisierung auf v25 erforderlich; v26 fungiert als Stepping‑stone release.
• Datenupgrade = Wartungsfenster – Unabhängig vom Dienstleister werden Clients getrennt, bis der Schritt durch ist; Rücksprünge mit erneuter Replikation sind nicht vorgesehen. Eine klassische Einbahnstraße. Das ist nicht mehr zeitgemäß!
• Konfigurationspakete sind kein Massen‑ETL – Für produktive Massenimporte rät Microsoft von Paketen ab (Performance‑Risiko) und verweist stattdesse auf XMLports.

Entscheidungsmatrix (kurz und bündig)

Risiken & Fallstricke, die wehtun

• Downtime unterschätzt: Beim Standard‑Upgrade ist der Datenupgrade‑Schritt hart; wer minutengenau planen muss, braucht saubere Vorab‑Tests oder wählt Livesync.
• Datenqualität: Dubletten, falsche Nummernkreise, fehlerhafte Dimensionen explodieren im neuen System. Frühzeitig Datenbereinigung einplanen.
• Add‑ons/Customizing: C/AL‑Anpassungen müssen sauber in AL/Extensions überführt werden; Aufwand hängt vom Altumfang ab.
• Konfigurationspakete überschätzt: Gut für Stammdaten – nicht als historienfähiges ETL oder bei laufender Produktion.

Checkliste: So treffen Sie die richtige Entscheidung (in 30 Minuten)

• Muss BC Online sein? Wenn ja und Sie sind < v25, kalkulieren Sie Zwischenschritt v25 (je älter die Quellversion, desto mehr Zwischenschritte sind notwendig) oder prüfen Sie Direktmigration/Livesync.
• Wie viel Historie brauchen Sie in BC? Nur Stammdaten -> RapidStart; volle Historie -> DataMigrate Pro oder Standard‑Upgrade mit Go‑Live‑Fenster und langen Ausfallzeiten.
• Downtime‑Toleranz: Null / Kaum Toleranz -> Livesync; Wochenend‑Cutover und hohe Kosten ok -> Standard‑Upgrade.
• NAV‑Version sehr alt? Direktmigration ohne Sprungversionen spart Zeit/Komplexität.
• Budget‑/Verantwortungsmodell: technisch getrieben & migrationsfokussiert -> DataMigrate Pro.

Siehe hierzu auch die offizielle Dokumentation von Microsoft.

Fazit

• Greenfield / „Grüne Wiese“: Konfigurationspakete für Stammdaten und Prozesse neu aufsetzen. Schnell, kosteneffektiv – aber nicht für Massenimporte im Live‑Betrieb.
• Komplette Datenübernahme: Wenn Downtime kritisch ist und Kosten niedrig gehalten werden sollen oder die Quellversion sehr alt: DataMigrate Pro (Parallelbetrieb, Livesync).
• Klassisches Cutover‑Fenster akzeptabel und Festpreis/Standard wichtig: Business Central Partner (wie IO Integrated) – akzeptieren Sie, dass das Datenupgrade eine Einbahnstraße ist und die Kosten ausufern können.