Polski (PL) 
English (United Kingdom) 
IFS Cloud Datenmigration · Checkliste 2026 · SCM und Distribution
Datenmigration nach IFS Cloud: Checkliste für SCM- und Distributionsdaten in fünf Phasen
Auf einen Blick
- Die Checkliste bezieht sich auf IFS Cloud 25R1/24R2 und konzentriert sich auf SCM- und Distributionsdaten. Sie behandelt Pflicht-Zeitstempel in UTC und die Abhängigkeit von REST-APIs, damit Daten nicht verfallen („Data Decay“).
- Geladen wird über Migration Jobs auf Basis von OData Projections statt über IALs. Eine Projection löst beim Laden die Geschäftslogik aus, eine Tabelle tut das nicht.
- Empfohlener Umfang für 2026: 2 Jahre Bewegungsdaten und 5 Jahre Stammdaten.
- Vor der Gesamtmigration läuft ein „Gold Load“: eine repräsentative 10-%-Stichprobe in der TEST-Umgebung deckt Randfälle im Mapping auf.
- Der Gesamtbestandswert des Altsystems muss nach dem Laden dem Wert in IFS Cloud entsprechen. Weichen sie ab, liegt der Fehler in der Migrationslogik der Artikelkosten (Part Costing).
Eine Datenmigration nach IFS Cloud braucht für jede SCM-Entität einen Verantwortlichen, harte Kriterien für saubere Daten und ein Mapping auf Projections statt auf Tabellen. Diese Checkliste (Stand 2026) führt Sie durch fünf Phasen, von der Governance vor dem ersten Extrakt bis zur laufenden Datenpflege nach dem Go-live.
1.Phase 1: Governance und Strategie vor der Migration
Bevor eine einzige Zeile extrahiert wird, brauchen Sie feste Spielregeln für die Daten.
- Datenverantwortliche benennen. Weisen Sie jeder SCM-Entität einen Business Process Owner zu: Der Leiter Einkauf zeichnet Lieferantendaten ab, der Lagerleiter verantwortet die Lagerorte der Artikel. Ohne Verantwortlichen bleiben Daten verwaist.
- Kriterien für „sauber“ festlegen. Definieren Sie strenge Prüfregeln. Beispiel: Kein Lieferant wird ohne gültige Steuer-ID und ohne einen ISO-3166-2-konformen Ländercode migriert. Was nicht sauber ist, wandert nicht.
- Evergreen-Umfang bestimmen. IFS Cloud ist eine Evergreen-Plattform, deshalb gehören 20 Jahre Altlasten nicht ins neue System. Empfehlung für 2026: 2 Jahre Bewegungsdaten und 5 Jahre Stammdaten. Das Altsystem wandert in ein Archiv (siehe Phase 5).
- Neue Pflichtfelder in SCM erfassen (Update 25R1). Identifizieren Sie neue Pflichtfelder wie die Emissions Class für Fracht oder die Secondary UoM für die hochgenaue Bestandsführung.
2.Phase 2: Extraktion und Analyse (Audit des Altsystems)
In dieser Phase kommen die technischen Altlasten ans Licht, die das neue IFS-Cloud-Umfeld sonst stören.
- Dublettenberichte laufen lassen. Suchen Sie doppelte Kunden- und Lieferantendatensätze. Durch die Global Extension-Funktionen in IFS Cloud soll ein Lieferant, den drei Gesellschaften nutzen, nur einmal in den Stammdaten stehen.
- Maßeinheiten (UoM) vereinheitlichen. „Each“, „EA“ und „Pc“ müssen auf einen einzigen IFS-Einheitencode abgebildet werden. Uneinheitliche Maßeinheiten erzeugen Phantombestände im Lager.
- Kundenspezifische Attribute erfassen. Prüfen Sie alle „Z-Felder“ und kundenspezifischen Altfelder. Entscheiden Sie, ob sie in IFS als Custom Attributes bleiben oder auf neue Standard-Entitäten aus 25R1 abgebildet werden.
- Zeichenlängen und UTF-8 prüfen. IFS Cloud arbeitet mit strengen Zeichenlängen, und Part Description 1 und 2 sind begrenzt. Finden Sie vor der Migration alle Datensätze, die gekürzt würden, damit keine Daten verloren gehen.
Technischer Baustein: SQL zur Prüfung der Maßeinheiten
Mit dieser Oracle-SQL-Abfrage finden Sie vor der Migration Unterschiede bei den Maßeinheiten:
SELECT unit_code, COUNT(*)
FROM legacy_inventory_parts
GROUP BY unit_code
HAVING COUNT(*) > 0;3.Phase 3: Datenmapping und technisches Modell
Phase 3 verbindet das Altsystem mit der Architektur aus Aurena-Oberfläche und OData in IFS Cloud.
- Altdaten auf IFS Projections abbilden. Mappen Sie nicht auf Tabellen, sondern auf Projections (zum Beispiel
PurchOrderaufPurchaseOrderProjection). So wird beim Laden die Geschäftslogik ausgelöst. - Zeitzonen berücksichtigen. Globale SCM-Prozesse verlangen 2026 UTC-Genauigkeit. Alle „Wanted Delivery Dates“ müssen von reinen Datumswerten in das Format
YYYY-MM-DD-HH24.MI.SSumgewandelt werden. - Standortbezogene Logik prüfen. Artikel müssen korrekt ihren Sites und Inventory Locations zugeordnet sein. Ein Lagerartikel ohne Site-Verknüpfung ist für die Planung unsichtbar.
4.Phase 4: Laden und Validieren
Der Erfolg dieser Phase misst sich an einer fehlerfreien Abstimmung zwischen Altsystem und IFS Cloud. Sie ist die Bewährungsprobe für Ihr Datenmodell.
- „Gold Load“ durchführen (Versuch 1). Migrieren Sie nicht alles auf einmal. Laden Sie eine repräsentative 10-%-Stichprobe in die TEST-Umgebung, um Mapping-Fehler in Randfällen aufzudecken.
- Finanzsalden abstimmen. Der Gesamtbestandswert des Altsystems muss dem Wert nach dem Laden in IFS Cloud entsprechen. Weicht er ab, prüfen Sie Ihre Migrationslogik für Part Costing.
- Permission Sets und Zeilenebenen-Sicherheit prüfen. Ein migrierter Benutzer in der Rolle „Einkauf“ darf innerhalb derselben Projection keine Felder mit Führungskräftegehältern sehen.
5.Phase 5: Governance nach dem Go-live
Die Migration endet nicht mit dem Go-live, sondern wechselt vom Bewegen der Daten zum Verteidigen ihrer Qualität.
- Zugriff auf das Altsystem abschalten. Verschieben Sie die SCM-Altdaten in ein schreibgeschütztes Archiv. So fallen Anwender nicht in alte Gewohnheiten zurück, und IFS Cloud bleibt die Single Version of the Truth. Klären Sie vorher, welche Aufbewahrungspflichten (etwa nach GoBD) für das Archiv gelten.
- History Logs aktivieren. Schalten Sie History Logs für sensible SCM-Attribute ein, zum Beispiel Lieferantenpreislisten. Das ergibt einen dauerhaften Prüfpfad für die Governance.
- Monatliche Datenprüfungen einplanen. Überwachen Sie mit IFS Lobbies und KI-gestützten Alerts Trends bei fehlerhaften Daten, etwa Artikel, die wiederholt ohne Lieferzeit erfasst werden.
6.Fragen und Antworten
Wie gehe ich bei der Migration mit negativen Lieferzeiten um?
IFS Cloud lässt keine Lieferzeiten kleiner 0 zu. Setzen Sie bei der Migration per SQL-Transformation für leere oder negative Werte eine Mindestlieferzeit von 1 Tag, damit die MRP-Berechnung nicht fehlschlägt.
Kann ich für Migrationen 2026 noch die alte IAL (Information Access Layer) verwenden?
IALs gibt es weiterhin, für Migrationen empfiehlt sich aber der Einsatz von Migration Jobs auf Basis von OData Projections. Sie stellen sicher, dass die Daten die Geschäftslogik des aktuellen IFS-Cloud-Releases einhalten, die IALs umgehen können.
Wie wirkt sich Evergreen auf die Strategie der Datenmigration aus?
Evergreen bedeutet, dass Daten laufend gepflegt werden müssen. Anders als bei älteren ERP-Systemen können Sie nicht zehn Jahre warten, bis Sie aufräumen. Führen Sie die Governance aus Phase 5 als monatlichen Dauerprozess ein, damit das System bei den halbjährlichen Updates nicht langsamer wird.
7.Über den Autor
Dariusz Myśliwiec: 18 Jahre Praxis mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängiger Berater, der remote in Europa und weltweit arbeitet.
Ausgewählte Kunden: 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.
Ihre Migrationsplanung mit mir durchgehen
Nennen Sie mir Ihr Altsystem, das Ziel-Release und die Datenobjekte, die in Phase 1 noch keinen Verantwortlichen haben. Daraus ergibt sich, wo ein Gold Load beginnt und welche Pflichtfelder fehlen. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Technisches 30-Minuten-Gespräch buchen Checkliste zur Governance lesen
