Polski (PL) 
English (United Kingdom) 
IFS Cloud · Datenmigration · Go-live
Datenmigration nach IFS Cloud: Altdaten bereinigen, bevor sie das neue System belasten
Die Datenmigration entscheidet über die Stabilität des Go-live. Altsysteme, die jahrzehntelang liefen, enthalten Dubletten, ausgelaufene Artikelnummern und unvollständige Kundensätze, und was ungeprüft nach IFS Cloud wandert, bremst das neue System und verfälscht die KI-gestützten Prognosemodelle vom ersten Tag an.
Auf einen Blick
- Die Hauptursache gescheiterter Migrationen ist die Datenqualität, nicht die technische Anbindung des Altsystems.
- Ein Schichtenmodell lädt in drei Stufen: Stammdaten, offene Salden und optional die Historie. Jede Stufe hat eigene Prüfregeln und einen eigenen Zeitrahmen.
- Die Migration ist ein Compliance-Ereignis: Veraltete personenbezogene Daten werden gelöscht und nicht migriert, und der Staging-Bereich unterliegt der DSGVO.
- Dauert das Laden der offenen Salden 48 Stunden, das Wochenendfenster beträgt aber nur 24, scheitert der Cutover. Probemigrationen messen die Ladezeit vorher.
1.Das Kernproblem: Datenqualität
Die Datenqualität des Altsystems bestimmt, ob die Migration gelingt. Ein Altsystem, das seit Jahrzehnten läuft, hat Dubletten, Artikel ohne Bewegung und Kundenstammsätze mit Lücken angesammelt. Gelangen diese Daten nach IFS Cloud, belasten sie die Abläufe im neuen System und füttern die Prognosemodelle mit Rauschen.
Die technische Anbindung zwischen Alt- und Neusystem ist nicht die Hauptursache gescheiterter Migrationen. Deshalb beginnt jede Migration mit festgelegten Bereinigungsregeln, die der Fachbereich abnimmt.
2.Das Schichtenmodell (ETL)
Ich migriere nie alles auf einmal, sondern in Schichten mit Extraktion, Transformation und Laden (ETL). Jede Schicht hat eine andere Prüftiefe und einen anderen Zeitdruck.
| Schicht | Inhalt | Besonderheit |
|---|---|---|
| 1 - Stammdaten (statisch) | Kunden, Lieferanten, Artikel, Konten | Hoher Prüfaufwand bei der Validierung |
| 2 - Offene Salden (dynamisch) | Lagerbestand, offene Verbindlichkeiten und Forderungen, offene Aufträge | Zeitkritisch, weil der Stand zum Cutover exakt stimmen muss |
| 3 - Historie (optional) | Abgeschlossene Transaktionen für die Berichterstattung | Besser in einem Data Lake archiviert als im produktiven ERP |
3.DSGVO und Datenresidenz
Eine Migration ist ein Compliance-Ereignis, denn Unternehmen im Europäischen Wirtschaftsraum müssen personenbezogene Daten auch während des Umzugs nach der DSGVO behandeln. Ich achte darauf, dass die Staging-Bereiche die regionalen Vorgaben zur Datenresidenz einhalten und dass veraltete personenbezogene Daten gelöscht und nicht migriert werden.
Wer Altdaten archiviert statt migriert, klärt vorher zwei Punkte: wie lange die gesetzlichen Aufbewahrungsfristen laufen und wie die Daten im Fall einer Betriebsprüfung nach GoBD zugänglich bleiben.
4.Die Chance des Neuanfangs
Die Migration eignet sich, um Mengeneinheiten zu vereinheitlichen, den Kontenrahmen zu straffen und die Lieferantenstammdaten zu bereinigen. Dieser Weg zahlt sich besser aus, als bestehende Unordnung schneller in das neue Werkzeug zu schieben.
5.Das Risiko des Cutover-Wochenendes
Das Go-live-Fenster ist begrenzt. Braucht der Ladevorgang der dynamischen Daten (Schicht 2) 48 Stunden, das Unternehmen hat aber nur ein Wochenendfenster von 24 Stunden, scheitert das Projekt. Deshalb führe ich Probemigrationen (Mock-Migrationen) durch, messe die Ladezeit genau und optimiere die Skripte auf Geschwindigkeit.
Bereitschaftsprüfung vor der Migration: Dateneigner je Fachbereich benannt, Bereinigungsregeln definiert und abgenommen, Stichtag für den Einfrierzustand des Altsystems festgelegt, Staging-Umgebung gesichert (DSGVO-konform). Eine ausführliche Liste steht im Beitrag Datenmigration in IFS Cloud: Governance-Checkliste.
6.Fragen und Antworten zur Datenmigration
Sollen wir die gesamte Transaktionshistorie von zehn Jahren und länger migrieren?
Im Grundsatz nein. Eine tiefe Transaktionshistorie im produktiven System kostet Geld, bremst die Systemleistung und erschwert spätere Upgrades. Üblich ist, die offenen Salden (aktive Daten) zu migrieren und die Historie in einem separaten, günstigeren Data Lake oder Berichtsspeicher abzulegen, auf den BI-Werkzeuge zugreifen.
Welche Werkzeuge werden für die Migration nach IFS Cloud eingesetzt?
Für standardisierte Ladevorgänge dient das native IFS Migration Cockpit (Data Migration Manager). Bei komplexen Transformationen aus Nicht-IFS-Altsystemen setze ich bei Bedarf zwischengeschaltete Staging-Datenbanken (SQL Server oder Oracle) und ETL-Skripte ein und lade die bereinigten Daten danach über REST-APIs oder Migration Jobs in IFS Cloud.
Wie bleiben die Daten während der Migration geschützt?
Die Staging-Umgebungen sind so gesichert wie die Produktion, der Zugriff folgt dem Need-to-know-Prinzip, und personenbezogene Daten können in den Testphasen anonymisiert oder maskiert werden, bis der endgültige Produktiv-Cutover erfolgt. Die DSGVO gilt für den Staging-Bereich genauso wie für das Zielsystem.
7.Über den Autor
Dariusz Myśliwiec: unabhängiger IFS-Berater mit 18 Jahren Praxis in IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert.
Ausgewählte Kunden aus meiner IFS-Arbeit: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
Planen Sie Ihre Migration in einem technischen 30-Minuten-Gespräch
Nennen Sie mir Ihr Altsystem, die Zahl der Stammdatensätze und das Zeitfenster für den Cutover. Wir klären, welche Daten migriert, welche archiviert und welche gelöscht werden. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
