Ein zwölf Jahre alter, vollständig abgeschlossener Kundenauftrag und ein heute noch offener Auftrag stehen beide im Altsystem. Trotzdem erfüllen sie beim ERP-Wechsel völlig unterschiedliche Aufgaben. Der offene Auftrag muss im neuen System weiterbearbeitet werden. Beim abgeschlossenen Auftrag wird vor allem ein verlässlicher Auskunfts- oder Nachweisweg benötigt.
Historische Daten beim ERP-Wechsel müssen deshalb nicht automatisch als operative Vorgänge in das neue ERP migriert werden. Entscheidend ist, wofür die Information nach dem Go-live gebraucht wird, in welcher Detailtiefe sie verfügbar sein muss und welcher Zugriffsweg diese Anforderung zuverlässig erfüllt.
Die Wahl lautet also nicht pauschal „alles migrieren“ oder „alles im Altsystem lassen“. Für einzelne Datenbestände können Migration, Verdichtung, Archiv, Berichtslösung oder ein zeitlich begrenzter Lesezugang jeweils richtig sein.
Historische Daten beim ERP-Wechsel: Was ist damit gemeint?
Historische Daten sind in diesem Zusammenhang abgeschlossene oder vergangene Informationen, die nach dem Go-live nicht mehr als aktiver Vorgang weitergeführt werden. Dazu können abgeschlossene Aufträge, Bestellungen, Buchungen, Produktionsmeldungen, alte Preisstände oder lang zurückliegende Stammdatenzustände gehören.
Davon zu trennen sind:
- aktive Stammdaten, die im neuen ERP für laufende Prozesse benötigt werden,
- offene Vorgänge, die nach dem Systemwechsel weiterbearbeitet werden müssen,
- Anfangsbestände und Salden, mit denen der operative Betrieb im Ziel startet,
- und historische Informationen, die vor allem für Auskunft, Analyse oder Nachweis relevant bleiben.
Diese Trennung ist wichtig, weil ein abgeschlossener Altbeleg nicht einfach wie ein neuer Zielbeleg behandelt werden kann. Würde er im neuen ERP erneut operativ angelegt, könnten Buchungen, Bestände oder Prozessstatus ungewollt beeinflusst werden.
Die erste Frage lautet: Was soll der Nutzer später tun können?
„Wir brauchen die Historie“ ist noch keine umsetzbare Anforderung. Der benötigte Zugriff kann sehr unterschiedlich aussehen:
- Der Kundenservice möchte eine alte Lieferung in wenigen Minuten finden.
- Der Vertrieb benötigt verdichtete Umsätze für Vergleiche.
- Die Buchhaltung muss Beleg und Buchungszusammenhang nachvollziehen.
- Die Qualitätssicherung sucht Chargen- oder Produktionsinformationen.
- Eine Prüfung verlangt bestimmte Originaldaten und deren Zusammenhang.
Für jeden historischen Bestand sollte daher ein konkreter Nutzungssatz formuliert werden: Wer benötigt welche Information, für welchen Zweck, wie häufig, in welcher Antwortzeit und mit welchen Beziehungen?
Erst danach lässt sich entscheiden, ob die Daten im operativen ERP, in einem Archiv, in einer Berichtslösung oder über das Altsystem bereitgestellt werden sollten.
Vier Wege für historische ERP-Daten
1. Vollständig in das neue ERP migrieren
Eine vollständige Übernahme kann sinnvoll sein, wenn historische Informationen im Zielprozess unmittelbar benötigt werden und das neue ERP einen geeigneten, sicheren Migrationsweg bietet. Das betrifft eher ausgewählte Datenarten als den gesamten Altbestand.
Der Aufwand ist hoch, wenn alte Belegketten, Status, Steuerlogiken und organisatorische Strukturen im Ziel rekonstruiert werden müssen. Außerdem unterstützen Standardmigrationsobjekte nicht zwangsläufig abgeschlossene historische Vorgänge. Für SAP S/4HANA Cloud Public Edition nennt SAP beispielsweise Stammdaten, offene Bewegungsdaten und Salden als initiale Bestände; historische Bewegungsdaten sind über den dort beschriebenen Migrationsweg nicht vorgesehen. Diese Grenze ist produktspezifisch, zeigt aber, warum die Zielmöglichkeit früh geprüft werden muss.
2. Einen ausgewählten Zeitraum oder bestimmte Belegarten übernehmen
Manchmal benötigt das Unternehmen nur jüngere Historie oder besonders wichtige Datenarten. Dann kann eine zeitliche oder fachliche Auswahl den Umfang begrenzen. Ein pauschales Datum reicht jedoch nicht immer. Ein älterer Servicefall kann weiterhin relevant sein, während ein jüngerer Routinebeleg keinen operativen Nutzen mehr besitzt.
Die Auswahlregel sollte deshalb Zeitraum, Status, Organisation, Datenobjekt und Verwendungszweck verbinden. Ausnahmen werden sichtbar dokumentiert.
3. Daten verdichten
Für Auswertungen kann eine Zusammenfassung genügen. Statt jede einzelne alte Buchung zu übernehmen, werden beispielsweise bestätigte Salden oder periodische Summen bereitgestellt. Dadurch bleiben Vergleichswerte erhalten, ohne den vollständigen alten Prozess im Ziel nachzubauen.
Verdichtung ist nur dann geeignet, wenn die benötigte Detailauskunft dadurch nicht verloren geht. Außerdem muss nachvollziehbar bleiben, aus welchem Altbestand und nach welcher Regel die Summe entstanden ist.
4. Historie außerhalb des operativen ERP bereitstellen
Ein Archiv, eine Berichtslösung, ein gesonderter lesender Datenbestand oder ein befristet betriebenes Altsystem kann für abgeschlossene Historie geeigneter sein. Die Informationen bleiben erreichbar, beeinflussen aber die täglichen Prozesse des neuen ERP nicht.
Dieser Weg ist keine bloße Ablageentscheidung. Er benötigt einen verantworteten Betrieb, Berechtigungen, Sicherung, Suchmöglichkeiten und einen getesteten Auskunftsprozess.
Ein Archiv ist mehr als ein Ordner mit Exportdateien
Mehrere CSV- und PDF-Dateien auf einem Netzlaufwerk sind noch kein verlässlicher historischer Zugriff. Selbst wenn die Dateien vollständig sind, kann später unklar sein, welche Kundennummer zu welchem Beleg gehört, welcher Status galt oder wie Tabellen miteinander verbunden werden.
Ein brauchbarer Archiv- oder Auskunftsweg beantwortet mindestens:
- Welche Daten und Dokumente sind enthalten?
- Wie werden Belege, Stammdaten und Beziehungen gemeinsam gefunden?
- Welche Schlüssel und alten Nummern bleiben suchbar?
- Wer darf auf welche Inhalte zugreifen?
- Wie werden Daten gesichert, wiederhergestellt und technisch betreut?
- Wie wird gezeigt, dass der übernommene Bestand vollständig und unverändert ist?
- Was geschieht, wenn das aktuelle Anzeige- oder Datenbankwerkzeug ersetzt werden muss?
Die zuständigen Rechts-, Steuer-, Datenschutz- und Fachverantwortlichen legen fest, welche Inhalte wie lange und in welcher Form verfügbar bleiben müssen. Eine Datenmigration darf diese Entscheidungen vorbereiten, aber nicht eigenständig treffen.
Der lesende Altzugang ist nur mit einem Betriebsplan belastbar
Das alte ERP vorerst schreibgeschützt weiterzubetreiben kann ein sinnvoller Übergangsweg sein. Er ist jedoch nur so lange verlässlich, wie Anwendung, Datenbank, Betriebssystem, Lizenzen, Zugänge und Know-how verfügbar bleiben.
Vor der Entscheidung müssen deshalb praktische Fragen geklärt werden:
- Wer betreibt und sichert das alte System nach dem Go-live?
- Wie lange sind Lizenz und technische Plattform unterstützt?
- Welche Benutzer erhalten einen Lesezugang?
- Wie werden Auskünfte erteilt, wenn der frühere Administrator nicht mehr verfügbar ist?
- Wie wird das System später geordnet abgeschaltet?
„Das Altsystem bleibt schon irgendwie erreichbar“ ist damit keine Archivstrategie. Es ist eine unbewertete technische Abhängigkeit.
Historie hängt an Stammdaten und alten Schlüsseln
Ein alter Auftrag ist nur verständlich, wenn Kunde, Artikel, Adressen, Einheiten, Preise und Status im damaligen Zusammenhang lesbar bleiben. Werden Stammdaten im neuen ERP zusammengeführt oder neu nummeriert, braucht der historische Zugriff weiterhin die alten Identitäten.
Dafür kann eine Alt-zu-Neu-Zuordnung helfen. Sie verbindet alte Schlüssel mit aktuellen Zielschlüsseln, ohne die historische Quelle umzuschreiben. Bei zusammengeführten Dubletten muss außerdem erkennbar sein, welche alten Kundennummern zum selben neuen Geschäftspartner gehören.
Dokumente verdienen eine eigene Betrachtung. Ein Belegbild ohne strukturierte Metadaten lässt sich schwer finden; ein strukturierter Datensatz ohne zugehöriges Dokument kann für die spätere Auskunft ebenfalls unvollständig sein.
Eine einfache Entscheidungsmatrix bringt Klarheit
Für jedes historische Datenobjekt können fünf Fragen bewertet werden:
- Operativer Bedarf: Muss der Bestand im neuen ERP weiterverarbeitet werden?
- Auskunftsbedarf: Wer benötigt welche Details und wie schnell?
- Nachweisanforderung: Welche Daten, Dokumente und Zusammenhänge müssen erhalten bleiben?
- Technische Zielmöglichkeit: Kann und soll das Zielsystem diesen Bestand überhaupt abbilden?
- Aufwand und Risiko: Was kostet Migration, Verdichtung, Archiv oder Altbetrieb – einschließlich späterer Betreuung?
Das Ergebnis wird nicht nur als „ja“ oder „nein“ dokumentiert. Je Bestand stehen Zielweg, Auswahlregel, Detailtiefe, Verantwortlicher, Prüfung und Abschaltbedingung fest.
Die übergeordnete Auswahl aller Datenobjekte behandelt der Beitrag Welche Daten gehören beim ERP-Wechsel ins neue System?. Die hier beschriebene Matrix vertieft darin gezielt die Historienentscheidung.
Historische Daten müssen vor der Abschaltung getestet werden
Ob Migration oder Archiv: Der Zugriff wird mit konkreten Auskunftsfällen geprüft. Geeignete Tests sind zum Beispiel:
- einen bekannten alten Auftrag über Kundennummer und Datum finden,
- Belegkopf, Positionen, Mengen, Preise und Status gemeinsam anzeigen,
- ein zugehöriges Dokument öffnen,
- einen verdichteten Wert auf seine Herkunft zurückführen,
- einen berechtigten und einen nicht berechtigten Zugriff prüfen,
- eine Stichprobe gegen das Altsystem oder den freigegebenen Export abgleichen,
- und eine Wiederherstellung beziehungsweise Ersatzbereitstellung erproben.
Diese Prüfung muss stattfinden, solange das Altsystem noch als Vergleich zur Verfügung steht. Nach seiner Abschaltung ist eine festgestellte Lücke deutlich schwieriger zu schließen.
Historie verändert Aufwand, Zeitplan und Angebot
„Historische Daten übernehmen“ kann eine kleine zusätzliche Exporttabelle oder die Rekonstruktion jahrelanger Belegketten bedeuten. Der Aufwand hängt nicht nur von der Zeilenzahl ab, sondern von Beziehungen, Zielweg, Auskunftstiefe, Dokumenten und Prüfnachweisen.
Deshalb sollte die Historie bereits im Migrationsumfang konkret beschrieben werden:
- Datenobjekt und Zeitraum,
- einbezogene Gesellschaften oder Standorte,
- benötigte Detailtiefe und Beziehungen,
- gewählter Ziel- oder Archivweg,
- Prüf- und Freigabekriterien,
- sowie ausdrücklich ausgeschlossene Bestände.
So bleibt eine spätere Historienforderung keine unerwartete Erweiterung kurz vor dem Go-live.
Typische Fehlversuche bei historischen ERP-Daten
- Alles vorsorglich ins neue ERP laden: abgeschlossene Vorgänge erhöhen Komplexität und können operative Prozesse beeinflussen.
- Nur ein pauschales Stichdatum verwenden: ältere relevante Fälle und jüngere irrelevante Daten werden falsch behandelt.
- CSV- und PDF-Exporte als fertiges Archiv betrachten: Suche, Beziehungen, Berechtigungen und Betrieb bleiben offen.
- Das Altsystem ohne Abschaltplan weiterlaufen lassen: Technik, Lizenz und Know-how werden zur dauerhaften Abhängigkeit.
- Nur Daten, aber keine Dokumente oder Schlüsselbeziehungen erhalten: der spätere Vorgang ist nicht vollständig nachvollziehbar.
- Den Zugriff erst nach dem Go-live testen: Lücken werden erkannt, wenn die beste Vergleichsquelle bereits fehlt.
Wer entscheidet über Migration und Archiv?
Fachbereiche beschreiben den späteren Nutzungs- und Auskunftsbedarf. Rechts-, Steuer-, Datenschutz- und weitere zuständige Stellen bestätigen die geltenden Anforderungen. IT und Zielsystemteam bewerten Betrieb, Sicherheit und technische Möglichkeiten. Die ERP-Projektleitung verbindet diese Entscheidungen mit Umfang, Budget und Abschaltplan.
Externe Migrationsunterstützung kann historische Datenbestände und Beziehungen analysieren, Entscheidungsvarianten mit Auswirkungen vorbereiten, ausgewählte Daten technisch migrieren oder einen strukturierten Export für den beschlossenen Auskunftsweg erzeugen. Die rechtliche und fachliche Entscheidung bleibt beim Unternehmen.
Die richtige Lösung beginnt beim späteren Zugriff
Historische Daten sind nicht deshalb im neuen ERP richtig aufgehoben, weil sie im alten vorhanden sind. Richtig ist der Weg, der den tatsächlichen Auskunfts-, Analyse- oder Nachweisbedarf erfüllt, ohne abgeschlossene Prozesse unnötig in die operative Zielstruktur zu zwingen.
Wenn in Ihrem ERP-Projekt noch unklar ist, welche Historie wirklich migriert werden muss und welcher Bestand besser außerhalb des neuen Systems verfügbar bleibt, können wir Datenquellen, Beziehungen und Zielmöglichkeiten strukturiert gegenüberstellen und daraus ein klar abgegrenztes, prüfbares Umsetzungspaket ableiten.