ERP-Einführung und Migration: Was vor der Software über den Erfolg entscheidet

Die teuerste Phase eines ERP-Projekts läuft, bevor eine Software installiert ist. Ein Leitfaden zu Vorarbeiten, Datenmigration und Go-Live, mit den Stellen, an denen Mittelständler regelmäßig stolpern.

pad systems 20. Mai 2026 6 min Lesezeit
ERP einführen ohne zu scheitern: Vorarbeiten, Migration, Go-Live als drei Phasen

Die teuerste Phase läuft ohne Software

Wenn ein Unternehmen mit dem Wunsch nach einem neuen ERP-System auf uns zukommt, ist die erste Frage meist eine technische: WinLine, ERPNext oder Odoo? Die ehrliche Antwort lautet, dass diese Frage zu früh kommt. Die Phase, die über Erfolg oder Scheitern eines ERP-Projekts entscheidet, läuft Monate bevor irgendeine Software installiert wird.

Das ist keine Beraterweisheit, sondern deckt sich mit dem, was die Zahlen sagen. Die größten Treiber für gesprengte Budgets sind nicht die Lizenzkosten, sondern unterschätzter Personalaufwand und schleichende Erweiterung des Projektumfangs (Panorama Consulting, 2025). Beides sind Vorarbeiten-Themen. Und über drei Viertel der gescheiterten Projekte scheitern nicht an der Software, sondern an Daten, Prozessen und Menschen.

Ein ERP ist kein Software-Kauf. Es ist ein Prozessprojekt. Wer das ernst nimmt, behandelt die Einführung in drei Phasen und gibt der ersten die Zeit, die sie braucht.

Phase 1: Die Vorarbeiten

Die Vorarbeiten sind die Phase, die am häufigsten übersprungen wird, weil sie sich nach Verzögerung anfühlt. Dabei verkürzt sie das Projekt, statt es zu verlängern.

Prozesse vor Funktionen. Ein gutes Lastenheft beschreibt, wie Auftrag, Beschaffung, Lager und Rechnung im Haus tatsächlich laufen, und wie sie laufen sollen. Es ist keine Funktionsliste. Wer Software nach Feature-Häkchen auswählt, bekommt ein System, das alle Häkchen erfüllt und trotzdem die eigenen Abläufe nicht abbildet. Bei einem Kunden haben wir in den ersten Workshops vier verschiedene Wege gefunden, wie aus einer Bestellung eine Rechnung wird, je nachdem, wer sie anlegt. Kein System bildet vier inoffizielle Prozesse sauber ab. Es musste erst einer werden.

Lastenheft und Pflichtenheft sind nicht dasselbe. Das Lastenheft beschreibt das WAS aus Sicht des Unternehmens, das Pflichtenheft das WIE des Anbieters. Letzteres ist vertraglich bindend. Wer diese Trennung nicht sauber zieht, zahlt die Missverständnisse später als Change-Request.

Datenbereinigung ist eine eigene Phase. Der Satz „die Daten bereinigen wir dann während der Migration” gehört zu den teuersten in jedem ERP-Projekt. Dazu gleich mehr. Wichtig ist hier nur: Die Sichtung und Bereinigung der Stammdaten beginnt in der Vorarbeit, nicht beim Import.

Den Umfang abgrenzen. Scope-Erweiterung ist einer der größten Budget-Killer. Die Gegenversicherung ist eine klare Priorisierung: Welche Prozesse sind Wettbewerbsvorteil und rechtfertigen Anpassung, welche folgen einfach dem Standard? Über 90 Prozent der Unternehmen passen ihr ERP an. Die Frage ist nicht ob, sondern an welcher einzigen Stelle es sich wirklich lohnt.

Phase 2: Die Migration

Wenn die Vorarbeit stimmt, ist die Migration handwerklich. Sie ist aber die Phase mit den meisten stillen Fallen.

Mit echten Daten testen, nicht mit sauberen. Eine Testmigration mit handverlesenen Beispieldatensätzen sieht immer gut aus. Die echte Datenbank ist dann zwölf Jahre alt: drei zusammengeführte Altsysteme, Kunden in zwei Schreibweisen, Artikelnummern in drei Formaten, Felder, die irgendwann für etwas anderes zweckentfremdet wurden. Eine Migration testet man mit dem Chaos, das tatsächlich gewachsen ist, inklusive aller Sonderfälle, die niemand mehr erklären kann.

Ein Mapping-Konzept gehört dokumentiert. Welches Altfeld landet in welchem neuen Feld? Diese Zuordnung wird vor der ersten Migration aufgeschrieben, nicht im Kopf des Beraters mitgeführt. Typische Defekte, die ein Mapping aufdeckt: Dubletten, tote Referenzen, uneinheitliche Formate. Ein Klassiker ist, dass inaktive Kunden beim Export weggelassen werden, und plötzlich hängen alte Bestellungen ohne Kundenbezug in der Luft.

Nicht alles muss mit. Migrieren ist nicht das Einzige, was man mit Altdaten tun kann. Vieles ist besser GoBD-konform archiviert als ins neue System geschleppt, etwa in einem read-only gehaltenen Altsystem oder einem Dokumentenarchiv. Das spart Aufwand und hält die Datenqualität sauber. Welche Historie ins ERP wandert und welche ins Archiv, ist eine bewusste Entscheidung, keine Default-Einstellung.

Müll rein, Müll raus. Das gilt bei der Migration eins zu eins, nur dass der Müll danach in einem teureren System liegt.

Phase 3: Der Go-Live

Ein ERP-Projekt scheitert selten am Stichtag selbst. Es scheitert an den Wochen davor.

Big-Bang oder stufenweise: eine Frage des Rollbacks. Für überschaubare Unternehmen ist der Big-Bang oft vertretbar: schnell, kein Parallelbetrieb, keine temporären Schnittstellen. Aber nur, wenn ein durchdachter Rollback-Plan in der Schublade liegt. Wer den nicht hat, fährt besser stufenweise, auch wenn das die Projektlaufzeit verlängert.

Schulung gehört vor den Go-Live. Der häufigste Fehler ist, das Training ans Ende zu schieben, zwischen Cutover und Tagesgeschäft, eine Stunde für alle. Die Folge: Drei Monate später nutzt die halbe Abteilung weiter das alte System, weil es „halt schneller geht”. Die Software ist dann nicht schlechter. Die Einweisung war es. Wir arbeiten über Key-User, die das Wissen ins Team tragen und Widerstände früh zurückmelden. Diese Key-User brauchen echte Projektzeit, kein „macht das bitte zusätzlich”.

Die Pflicht, an die kaum jemand denkt. Die GoBD-Verfahrensdokumentation muss beim Systemwechsel aktualisiert werden. Eine Migration ist ein dokumentationspflichtiger Vorgang, und die Dokumentation ist zehn Jahre aufzubewahren. Wer das erst nach dem Go-Live merkt, hat ein Compliance-Problem statt einer Randnotiz.

Ein guter Go-Live fühlt sich unspektakulär an. Am Montag arbeiten die Leute im neuen System, ohne Hintertür zum alten. Langeweile am Stichtag ist das beste Zeichen, dass die Vorarbeit gestimmt hat.

Die Systemfrage kommt zuletzt

Erst wenn Prozesse und Datenlage geklärt sind, lohnt sich der Blick auf die Software. Wir beraten herstellerneutral. Drei Systeme führen wir selbst ein:

WinLine von mesonic ist das bewährte ERP für den deutschsprachigen Mittelstand: DACH-nativ, mandantenfähig, mit gestufter DATEV-Schnittstelle bis hin zum bidirektionalen Austausch. Die Buchhaltungs-Integration ist hier eher Konfiguration als Entwicklung. Als mesonic-Partner führen wir WinLine direkt ein und betreuen den Betrieb.

ERPNext auf Basis des Frappe-Frameworks ist die Open-Source-Antwort: über Doctypes beliebig erweiterbar, mit voller Datenhoheit und transparentem Lizenzmodell. Der deutsche Kontenrahmen und eine DATEV-Brücke gehören hier zur Vorarbeit, nicht zum Standard. Dafür gibt es keinen Vendor-Lock-in.

Odoo ist das modulare ERP mit breitem Funktionsumfang von CRM bis Fertigung. SKR03 und SKR04 sind im Standard dabei; für einen sauberen DATEV-Export ist in der Regel ein erweiterter Connector nötig. Bei Odoo-Projekten arbeiten wir mit der KONMATIK GmbH zusammen.

Welches dieser Systeme passt, ergibt sich aus den Prozessen, der Buchhaltung und dem Anspruch an Datenhoheit, nicht aus einem Datenblatt-Vergleich.

Passt keines der drei? Wir sind nicht darauf festgelegt. Dieselbe Vorarbeit hilft dann, herstellerneutral ein anderes ERP auszuwählen, und wir suchen den passenden Einführungspartner dafür.

Wie wir das machen

Wir beginnen jedes ERP-Projekt mit den Vorarbeiten: Prozesse aufnehmen, Datenlage klären, Umfang abgrenzen. Erst danach fällt die Systementscheidung, dann folgen Migration und Go-Live, mit Schulung, Rollback-Plan und aktualisierter GoBD-Dokumentation. Die Software ist das letzte Drittel der Entscheidung, nicht das erste.

Wer einen Wechsel plant, findet die Details in unserem Angebot zur ERP-Einführung und Migration.

LinkedIn
Dieser Hinweis existiert nur, weil alle anderen einen haben. Keine Cookies an Bord.