Datenmigration in ein neues ERP, ohne die Historie zu verlieren

Der Austausch eines ERP-Systems ist eines der risikoreichsten Projekte, die ein Unternehmen angehen kann, und der Teil, der Führungskräften den Schlaf raubt, ist selten die Software selbst. Es sind die Daten. Jahrelange Kundendaten, Lieferantenkonditionen, Produktkataloge, offene Rechnungen und gebuchte Transaktionen bilden das operative Gedächtnis des Unternehmens. Bewegt man sie unachtsam, kann man Berichte zerstören, Prüfpfade verlieren und den Tagesbetrieb wochenlang lahmlegen. Dieser Leitfaden zeigt, wie man Daten in ein neues ERP migriert, ohne die Historie zu verlieren, die den Zahlen ihre Bedeutung gibt, und behandelt die Entscheidungen, den Prozess und die Kontrollen, die einen reibungslosen Umstieg von einem teuren trennen.

Warum ERP-Datenmigration um Historie geht, nicht nur um Datensätze#

Es ist verlockend, Migration als mechanische Kopieraufgabe zu behandeln: Zeilen aus der alten Datenbank ziehen, in die neue schieben und weitermachen. In Wirklichkeit speichert ein ERP nicht nur Daten, sondern die Beziehungen und den Kontext, die Daten nutzbar machen. Eine Rechnung ist ohne den Kunden, den Auftrag, den Steuerschlüssel und die Sachkonten, die sie berührt, bedeutungslos. Historische Transaktionen tragen Trendanalysen, Steuerprüfungen, Gewährleistungsfälle und den Kundenservice. Migriert man nur aktuelle Salden und verwirft die Details dahinter, spart man am Anfang Zeit, macht die Organisation aber dauerhaft blind für die eigene Vergangenheit. Ziel ist nicht bloß, Datensätze zu verschieben, sondern ihre Bedeutung zu bewahren, damit ein im nächsten Jahr erstellter Bericht noch mit den in diesem Jahr abgeschlossenen Büchern übereinstimmt.

Bestandsaufnahme der Altdaten, bevor Sie sie anfassen#

Jede ernsthafte Migration beginnt mit der Erkundung. Bevor Sie ein einziges Feld abbilden, katalogisieren Sie, was tatsächlich im Quellsystem lebt: welche Tabellen, wie viele Datensätze, wie weit die Historie zurückreicht und welche Daten noch von aktiven Prozessen referenziert werden. Befragen Sie die Nutzer jedes Moduls, denn das wahre System of Record ist oft eine Mischung aus ERP, Tabellenkalkulationen und Schattendatenbanken, die niemand dokumentiert hat. Profilieren Sie die Daten, um Qualität zu messen, Dubletten zu zählen und Felder zu finden, die leer, inkonsistent oder zweckentfremdet sind. Diese Bestandsaufnahme wird zum Scope des gesamten Projekts. Sie zu überspringen ist der Grund, warum Teams drei Tage vor dem Go-live entdecken, dass zehn Jahre Anhänge in einem Ordner außerhalb der Datenbank liegen und nie Teil des Plans waren.

Entscheiden, was zu migrieren ist: Stammdaten, offene Posten und Historie#

Nicht alles verdient die Reise ins neue System, und alle Daten gleich zu behandeln verschwendet Aufwand und Risikobudget. Teilen Sie Ihre Daten in drei Gruppen. Stammdaten — Kunden, Lieferanten, Produkte, Kontenplan, Mitarbeiter — sind essenziell und müssen sauber sein, denn Fehler pflanzen sich hier in jede Transaktion fort. Offene Posten — unbezahlte Rechnungen, offene Bestellungen, laufende Fertigungsaufträge, aktueller Bestand — müssen exakt migriert werden, damit der Betrieb am ersten Tag weiterläuft. Historische Transaktionen — abgeschlossene und gebuchte Belege — sind der Punkt, an dem Teams uneins sind. Manche migrieren volle Details; andere laden zusammengefasste Salden ins ERP und behalten die Details in einem zugänglichen Archiv. Beides ist gültig, doch die Wahl muss bewusst und dokumentiert sein, getrieben von gesetzlichen Aufbewahrungsregeln und Reporting-Bedarf, nicht von Bequemlichkeit.

Datenbereinigung: das Chaos vor dem Umzug beheben#

Die Migration ist die beste Gelegenheit, die Ihr Unternehmen je haben wird, seine Daten zu bereinigen, und der schlechteste Zeitpunkt, das Chaos zu ignorieren. Schmutzige Daten, die in ein glänzendes neues ERP wandern, bleiben schmutzig und verderben ab der ersten Woche Berichte und frustrieren Nutzer. Deduplizieren Sie Kunden- und Lieferantendatensätze, standardisieren Sie Formate für Adressen, Währungen und Maßeinheiten, mustern Sie veraltete Produkte aus und stimmen Sie Salden gegen das Hauptbuch ab. Vergeben Sie klare Verantwortung: Die Finanzabteilung validiert Konten, der Vertrieb Kunden, der Einkauf Lieferanten. Bereinigung ist mühsam und politisch, weil sie jahrelange angesammelte Abkürzungen offenlegt, aber es ist weit günstiger, einen Datensatz einmal in einem Staging-Bereich zu korrigieren, als seine Folgen durch ein produktives System zu jagen.

Feldzuordnung zwischen altem und neuem System#

Keine zwei ERP-Systeme modellieren die Welt identisch. Ein einzelnes Feld in der Altanwendung kann sich im neuen in drei aufteilen oder umgekehrt; Statuscodes, Steuerkategorien und Kontenstrukturen passen selten zusammen. Feldzuordnung ist die disziplinierte Arbeit, für jedes Quellfeld zu dokumentieren, wohin seine Daten im Zielsystem landen, wie Werte übersetzt werden und welcher Standard gilt, wenn die Quelle leer ist. Erstellen Sie eine Mapping-Spezifikation, die Fachbereiche, nicht nur die IT, prüfen und freigeben. Achten Sie besonders auf Identifikatoren: Die Primärschlüssel, die Kunden mit Aufträgen und Aufträge mit Rechnungen verbinden, müssen erhalten oder verlässlich neu verknüpft werden, sonst brechen die Beziehungen, die der Historie ihre Bedeutung geben, beim Laden lautlos.

Der ETL-Prozess: Extrahieren, Transformieren, Laden#

Das mechanische Herz der Migration ist ETL: Daten aus der Quelle extrahieren, sie an das Zielmodell und die Geschäftsregeln anpassen und in das neue ERP laden. Extrahieren Sie in eine Staging-Umgebung, statt gegen die Live-Quelle zu arbeiten, damit Sie risikofrei iterieren können. Die Transformationsstufe wendet Ihre Zuordnungs- und Bereinigungsregeln an, konvertiert Formate und reichert Datensätze bei Bedarf an. Die Ladestufe fügt die Daten ein, idealerweise über die validierten Importschnittstellen oder APIs des ERP statt über direkte Datenbankschreibvorgänge, damit die eigenen Integritätsprüfungen des Systems Probleme erkennen. Behandeln Sie ETL wie Software: versionieren Sie die Skripte, protokollieren Sie jeden Lauf und machen Sie die gesamte Pipeline wiederholbar, damit ein Dutzend Testläufe Sie Zeit kosten und nicht schlaflose Improvisation.

Validierung und Abstimmung nach dem Laden#

Ein Ladevorgang, der ohne Fehlermeldung endet, ist keine erfolgreiche Migration; er ist eine ungetestete. Validierung beweist, dass die Daten korrekt und vollständig angekommen sind. Stimmen Sie die Datensatzzahlen zwischen Quelle und Ziel ab, bestätigen Sie, dass die finanziellen Kontrollsummen — Saldenliste, Forderungen, Verbindlichkeiten, Bestandswert — auf den Cent genau übereinstimmen, und prüfen Sie einzelne Belege stichprobenartig durchgängig. Lassen Sie Fachanwender ihre echten täglichen Aufgaben gegen migrierte Daten in einer Staging-Umgebung testen, bevor sich jemand zum Go-live verpflichtet. Bauen Sie automatisierte Prüfungen, die Schlüsselkennzahlen vergleichen und Abweichungen markieren, denn menschliche Augen übersehen einen Rundungsfehler, der sich über eine Million Zeilen verbirgt. Erst wenn die Zahlen stimmen und die Nutzer dem Gesehenen vertrauen, ist die Migration wirklich fertig.

Umstiegsstrategien: Big Bang vs. stufenweise#

Wie Sie den Schalter umlegen, prägt Ihr Risiko. Ein Big-Bang-Umstieg bewegt alles in einem einzigen Moment ins neue ERP, meist über ein Wochenende oder einen Feiertag. Er ist schneller und vermeidet den Schmerz, zwei Systeme parallel zu betreiben, konzentriert aber das Risiko: Bricht etwas, ist das ganze Unternehmen auf einmal betroffen. Ein stufenweiser Ansatz migriert nach Modul, Standort oder Region über die Zeit, begrenzt das Risiko und lässt das Team lernen, um den Preis temporärer Integrationen zwischen altem und neuem System. Es gibt keine allgemeingültig richtige Antwort. Kleinere, einfachere Betriebe bevorzugen oft den Big Bang; große, komplexe Unternehmen mit mehreren Standorten gehen meist stufenweise vor. Was auch immer Sie wählen, proben Sie den Umstieg vollständig und halten Sie einen getesteten Rollback-Plan bereit, den Sie wirklich einzusetzen bereit sind.

Historische Aufzeichnungen für Audit und Compliance bewahren#

Selbst wenn Sie entscheiden, die volle Historie nicht ins Live-ERP zu laden, haben Sie selten die Freiheit, sie zu verwerfen. Steuerbehörden, Branchenaufsichten und Verträge schreiben Aufbewahrungsfristen vor, die oft sieben Jahre oder länger betragen, und ein Prüfer kann eine bestimmte Transaktion aus Jahren zuvor sehen wollen. Bewahren Sie historische Details in einem dokumentierten, zugänglichen Archiv — einer schreibgeschützten Reporting-Datenbank, einem Archivsystem oder exportierten Dateien mit definierter Struktur — und stellen Sie sicher, dass jemand sie tatsächlich abrufen und interpretieren kann. Halten Sie fest, wo die Historie liegt, wie sie zum neuen System passt und wie lange sie aufbewahrt werden muss. Die Historie zu verlieren ist nicht nur eine betriebliche Unannehmlichkeit; je nach Rechtsraum und Branche kann es ein Compliance-Versagen mit echten finanziellen und rechtlichen Folgen sein.

Häufig gestellte Fragen#

Soll ich alle historischen Transaktionen ins neue ERP migrieren? Nicht unbedingt. Die vollen Details zu migrieren hält alles an einem Ort, erhöht aber Kosten, Komplexität und Risiko und kann das neue System mit Daten verlangsamen, die Nutzer selten anfassen. Ein verbreiteter Kompromiss ist, Stammdaten und offene Posten sowie ein begrenztes Fenster jüngerer Historie — oft zwei bis drei Jahre — ins Live-ERP zu laden und ältere Details in einem zugänglichen Archiv zu halten, das Audit- und gesetzliche Aufbewahrungsanforderungen erfüllt. Das richtige Gleichgewicht hängt von Ihrem Reporting-Bedarf, den regulatorischen Pflichten und dem Aufwand ab, den die älteren Daten zum Bereinigen und Abbilden erfordern würden.

Wie lange dauert eine ERP-Datenmigration üblicherweise? Das variiert enorm mit Datenvolumen und -qualität, doch Migration ist selten eine schnelle Aufgabe und läuft oft über mehrere Monate neben der breiteren Einführung. Das Laden selbst mag Stunden dauern; die Erkundung, Bereinigung, Zuordnung und die wiederholten Testläufe, die das Laden vertrauenswürdig machen, dauern weit länger. Teams, die Migration kurz vor dem Go-live als Nebensache behandeln, bereuen es fast immer. Beginnen Sie früh, bereinigen Sie kontinuierlich und planen Sie Budget für mehrere vollständige Probeläufe ein, statt das Unternehmen auf einen einzigen Produktivlauf zu setzen.

Fazit#

Die Migration in ein neues ERP ohne Verlust der Historie geht weniger um clevere Werkzeuge als um Disziplin: Inventarisieren Sie, was Sie haben, entscheiden Sie bewusst, was mitkommt, bereinigen Sie es vor dem Umzug, bilden Sie es sorgfältig ab und beweisen Sie durch Abstimmung, dass es unversehrt angekommen ist. Bewahren Sie die historischen Details, auf die Ihr Unternehmen und Ihre Aufsichten angewiesen sind, ob im neuen System oder in einem vertrauenswürdigen Archiv. Machen Sie das gut, und Ihr neues ERP startet mit Daten, denen Nutzer vertrauen, und einer Vergangenheit, die noch mit der Gegenwart übereinstimmt. Machen Sie es nachlässig, und Sie erben die Probleme des alten Systems ohne dessen Vertrautheit. In der Migration, nicht in der Software, wird ein ERP-Projekt meist gewonnen oder verloren.