Das Wichtigste in Kürze
- Der Aufwand hängt an den Prozessen und den Daten, kaum an der Zahl der Anwender. Zwei gleich große Unternehmen können um ein Vielfaches auseinanderliegen.
- Die Datenmigration ist fast immer der unterschätzte Posten — und die Frage, wie viel Historie mitwandert, ist eine bewusste Kostenentscheidung.
- Eine Testmigration mit echten Daten, die von den Fachbereichen abgenommen wird, ist der wirksamste Schutz vor einem gescheiterten Go-Live.
- Projekte scheitern selten an der Technik. Sie scheitern an unklarem Umfang, fehlender Entscheidungsfähigkeit und daran, dass die Anwender zu spät eingebunden werden.
- Ein Umstieg innerhalb einer Produktlinie — etwa von Dynamics NAV auf Business Central — ist deutlich planbarer als ein Wechsel des Herstellers.
Wann ein Wechsel fällig ist — und wann nicht
Nicht jedes Ärgernis rechtfertigt ein Migrationsprojekt. Ein System, das im Standard läuft, gepflegt wird und die Prozesse trägt, wird nicht dadurch besser, dass es neu ist. Vier Gründe tragen einen Wechsel dagegen zuverlässig:
Fehlt keiner dieser Punkte, lohnt die ehrliche Gegenprobe: Ließe sich das eigentliche Problem auch durch Aufräumen im bestehenden System lösen? Häufig ist die Antwort ja — und dann ist Aufräumen die deutlich günstigere Maßnahme.
- Der Hersteller-Support läuft aus, Sicherheitsupdates bleiben aus
- Das System blockiert Vorhaben, die geschäftlich anstehen — Cloud-Betrieb, Automatisierung, moderne Schnittstellen
- Die Anpassungen sind so gewachsen, dass Updates riskant und Änderungen teuer geworden sind
- Gesetzliche Anforderungen lassen sich nicht mehr sauber abbilden, etwa bei der E-Rechnung
Der Ablauf in fünf Phasen
Die Reihenfolge ist in fast allen Projekten dieselbe; was sich unterscheidet, ist die Tiefe je Phase. Wer eine davon überspringt, holt sie später unter schlechteren Bedingungen nach.
- Bestandsaufnahme: Welche Prozesse laufen heute wie, welche Anpassungen und Schnittstellen sind im Einsatz, welche davon nutzt noch jemand
- Sollkonzept: Was soll der Standard übernehmen, was bleibt individuell, was fällt ersatzlos weg — hier wird der Aufwand tatsächlich festgelegt
- Aufbau und Anpassung: Einrichtung, Erweiterungen, Schnittstellen, Berechtigungen, Berichte
- Testmigration und Abnahme: echte Daten in einer Testumgebung, geprüft von den Menschen, die täglich damit arbeiten
- Go-Live und Nachbetreuung: der Produktivwechsel und die Wochen danach, in denen die letzten Sonderfälle auftauchen
Datenmigration: welche Daten wirklich mitmüssen
Die Frage wird meist zu spät gestellt und dann reflexhaft mit alles beantwortet. Das ist teuer und selten nötig. Sinnvoll ist eine bewusste Einteilung in drei Gruppen.
Stammdaten wandern immer mit: Kunden, Lieferanten, Artikel, Konten, Preise. Sie sind der Kern und gleichzeitig die beste Gelegenheit zum Aufräumen — Karteileichen, Dubletten und Artikel, die es seit Jahren nicht mehr gibt, müssen nicht ins neue System.
Offene Vorgänge müssen ebenfalls mit: unbezahlte Rechnungen, offene Bestellungen und Aufträge, Lagerbestände. Ohne sie ist das System am ersten Tag nicht arbeitsfähig.
Die Historie ist die eigentliche Entscheidung. Abgeschlossene Belege früherer Jahre lassen sich migrieren, in verdichteter Form übernehmen oder im Altsystem beziehungsweise in einem Archiv belassen. Für Auskünfte und Prüfungen reicht ein lesender Zugriff auf das Archiv fast immer aus, und der Migrationsaufwand sinkt spürbar. Die handels- und steuerrechtlichen Aufbewahrungspflichten bleiben davon unberührt und sollten mit dem Steuerberater abgestimmt werden.
Wie lange es dauert und was die Dauer treibt
Eine Zahl ohne Kontext wäre unseriös, weil die Spannweite gewaltig ist. Was sich seriös sagen lässt, ist, woran die Dauer hängt — und das sind fast nie die Anwenderzahlen.
Ein Umstieg innerhalb einer Produktlinie, etwa von Dynamics NAV auf Business Central, ist deutlich planbarer als ein Herstellerwechsel: Datenmodell und Begriffe bleiben verwandt, die Anwender erkennen ihre Abläufe wieder, und für die Datenübernahme gibt es etablierte Werkzeuge. Ein Wechsel auf ein fremdes System bedeutet dagegen, jeden Prozess neu zu denken.
- Zahl und Tiefe der Anpassungen im Altsystem — in der Regel der größte Treiber
- Anzahl und Art der Schnittstellen, besonders alter dateibasierter Verbindungen
- Wie viel Historie übernommen werden soll und in welcher Tiefe
- Verfügbarkeit der Fachbereiche für Tests und Entscheidungen
- Zahl der Gesellschaften und Standorte, die mitwandern
Woran Projekte tatsächlich scheitern
Nach vielen Projekten fällt auf, dass die Fehlerbilder sich wiederholen — und dass die Technik selten darunter ist. Die häufigsten sind: ein Umfang, der nie schriftlich festgehalten wurde und deshalb im Laufe des Projekts wächst; eine Entscheidungsstruktur, in der niemand Prozessfragen abschließend beantworten darf; Anwender, die das neue System zum ersten Mal in der Schulungswoche sehen; und eine Testphase, die gekürzt wird, weil der Go-Live-Termin schon kommuniziert ist.
Alle vier sind Führungsfragen, keine IT-Fragen. Der wirksamste Einzelhebel ist die Testmigration mit echten Daten, die von den Fachbereichen wirklich durchgearbeitet und formal abgenommen wird. Wer hier Zeit spart, bezahlt sie nach dem Go-Live mit Zinsen.
Häufige Fragen
- Die Spannweite ist zu groß für eine pauschale Zahl. Belastbar wird die Aussage erst nach einer Bestandsaufnahme, weil die Dauer an der Tiefe der Anpassungen, der Zahl der Schnittstellen und dem Umfang der Datenübernahme hängt — nicht an der Unternehmensgröße. Ein weitgehend im Standard betriebenes System ist ein überschaubares Projekt, eine über fünfzehn Jahre gewachsene Speziallösung deutlich mehr.
- Nein, und es ist meist auch nicht sinnvoll. Stammdaten und offene Vorgänge müssen mit. Bei der Historie haben Sie die Wahl zwischen Migration, verdichteter Übernahme und Archivierung. Für Auskünfte reicht ein lesender Archivzugriff fast immer, und der Aufwand sinkt deutlich. Die Aufbewahrungspflichten bleiben davon unberührt.
- Weitgehend ja. Aufbau, Testmigration und Abnahme laufen parallel zum Tagesgeschäft im Altsystem. Nur der Produktivwechsel selbst braucht ein Zeitfenster, in dem nicht gebucht wird — üblicherweise ein Wochenende. Was Zeit kostet, ist nicht der Stillstand, sondern die Mitarbeit der Fachbereiche in der Testphase; die sollte eingeplant und nicht nebenher erwartet werden.
- Bei einer Einführung gibt es kein Vorgängersystem, aus dem Daten und Prozesse übernommen werden müssen — dafür fehlt auch die gewachsene Struktur, an der man sich orientieren kann. Ein Wechsel bringt Datenmigration, Schnittstellen und eingespielte Abläufe mit, die abgelöst werden müssen. Der Wechsel ist technisch aufwendiger, die Einführung organisatorisch.
- Häufig ja, weil beim Wechsel ohnehin jede Anpassung angefasst wird — das ist der günstigste Zeitpunkt, sie cloud-fähig zu machen. Der Cloud-Betrieb nimmt Serverbetrieb, Update-Aufwand und Infrastrukturkosten ab; im Gegenzug entfallen direkte Datenbankeingriffe und Sonderwege. Ob es passt, entscheidet sich an Ihren Anpassungen und Schnittstellen, nicht an einer generellen Cloud-Strategie.