Datenmigration für sichere Systemwechsel
Datenmigration hilft Unternehmen, bestehende Daten strukturiert aus Quell- und Altsystemen in neue Zielsysteme zu überführen – etwa bei ERP-Wechsel, Shop-Relaunch, PIM-Einführung oder der Ablösung bestehender Anwendungen.
Wenn Systeme gewechselt oder modernisiert werden, entscheidet die Vorbereitung der Datenmigration wesentlich darüber, wie gut vorhandene Informationen im neuen Zielsystem weiterverwendet werden können. Kunden-, Artikel-, Lieferanten-, Preis-, Produkt- oder Auftragsdaten liegen häufig in unterschiedlichen Strukturen, Formaten und Qualitätsständen vor. Ohne klare Vorbereitung können bestehende Fehler, veraltete Bestände oder ungeeignete Datenstrukturen in das neue System übernommen werden.
Eine strukturierte Datenmigration beginnt deshalb vor der eigentlichen Übertragung. Zunächst sollte geklärt werden, welche Daten benötigt werden, welche Bestände bereinigt oder ausgeschlossen werden sollten und wie Informationen aus dem Quellsystem auf die Struktur des Zielsystems abgebildet werden. Erst danach folgen technische Übertragung, Testmigration und Validierung.
maexware unterstützt Unternehmen dabei, Datenmigration als eigenen Projektbaustein eines Systemwechsels zu planen und technisch umzusetzen. Im Mittelpunkt stehen die Analyse der Ausgangsdaten, ihre Vorbereitung für das Zielsystem, Mapping und Transformation sowie die kontrollierte Test- und finale Datenübernahme.
Warum Datenmigration bei Systemwechseln wichtig ist
Eine Datenmigration ist ein zentraler Bestandteil vieler Systemwechsel. Wie gut Daten für das neue Zielsystem vorbereitet werden, beeinflusst wesentlich, wie zuverlässig sie nach der Umstellung weiterverwendet werden können. Unvollständige, doppelte, veraltete oder fachlich ungeeignete Daten aus dem Altsystem können sonst in das neue Zielsystem übernommen werden.
Besonders bei ERP-Wechsel, Shop-Relaunch, PIM-Einführung, Warenwirtschaftswechsel oder CRM-Migration treffen bestehende Datenbestände häufig auf neue Strukturen, Pflichtfelder und Systemlogiken. Kundenadressen, Artikelnummern, Preis- und Konditionsdaten, Lieferanteninformationen, Produktdaten, Bestellungen oder historische Daten müssen deshalb daraufhin geprüft werden, ob und in welcher Form sie im Zielsystem weiterverwendet werden sollen.
Wird eine Datenmigration nicht ausreichend vorbereitet, können unvollständige Datensätze, Dubletten, ungeeignete Feldzuordnungen, fehlende Beziehungen, ungültige Formate oder nicht passende Werte entstehen. Solche Abweichungen werden teilweise erst bei Testmigrationen oder nach dem Go-live sichtbar und können zusätzliche Korrekturen und Abstimmungen erforderlich machen.
Deshalb sollte die Datenmigration frühzeitig als eigener Bestandteil des Systemwechsels geplant werden. Migrationsumfang, Ausgangsdaten, Anforderungen des Zielsystems sowie notwendige Prüf- und Testschritte sollten geklärt sein, bevor die finale Datenübernahme vorbereitet wird. Wie eine solche Vorbereitung aufgebaut werden kann, zeigt unser Beitrag zum Datenmigration-Konzept.
Typische Szenarien für Datenmigration
Datenmigration wird relevant, wenn bestehende Daten in eine neue Systemumgebung übernommen werden sollen. Das kann ein vollständiger Systemwechsel sein, aber auch ein Relaunch, die Einführung einer neuen Plattform, die Ablösung einzelner Anwendungen oder die Zusammenführung mehrerer Datenquellen.
Typische Szenarien sind ERP-Wechsel, Shop-Relaunch, PIM-Einführung, Warenwirtschaftswechsel, CRM-Migration oder Systemkonsolidierung. Welche Daten übernommen werden und welche Vorbereitung erforderlich ist, unterscheidet sich je nach Ausgangssystem, Zielsystem und Nutzung der Daten im jeweiligen Geschäftsprozess.
| Szenario | Typische Daten | Worauf bei der Migration geachtet werden sollte |
|---|---|---|
| ERP-Wechsel | Kunden, Artikel, Lieferanten, Preis- und Konditionsdaten, Belege, Stammdaten und historische Daten. | Pflichtfelder, Dubletten, Belegbeziehungen, Nummernkreise, Preislogiken und Strukturen des neuen ERP-Systems prüfen. |
| Shop-Relaunch | Produkte, Kategorien, Kundenkonten, Bestellungen, Medien, Produkttexte und SEO-relevante Daten. | URLs, Produktzuordnungen, Varianten, Medien, Kategorien und Bestellhistorien für die neue Shop-Struktur vorbereiten. |
| PIM-Einführung | Produktdaten, Attribute, Varianten, Kategorien, Medien, Sprachen und weitere Produktinformationen. | Bestehende Produktdaten auf das Datenmodell, die Attributlogik und die Variantenstruktur des neuen PIM-Systems abbilden. |
| Warenwirtschaftswechsel | Artikel, Einheiten, Lagerdaten, Bestände, Lieferanten, Einkaufspreise und operative Handelsdaten. | Artikelstrukturen, Einheiten, Lagerlogik, Bestandsbezug und Anforderungen angrenzender Systeme berücksichtigen. |
| CRM-Migration | Kunden, Kontakte, Ansprechpartner, Beziehungen, Aktivitäten, Vertriebsdaten und Kommunikationshistorien. | Dubletten, Kontaktbeziehungen, Historien, Feldzuordnungen und für das Projekt relevante Datenschutzanforderungen berücksichtigen. |
| Systemkonsolidierung | Daten aus mehreren Quellen, Altsystemen, Tabellen, Datenbanken oder Teilanwendungen. | Datenquellen abgleichen, Dubletten erkennen, Zielstrukturen definieren und widersprüchliche Werte vor der Übernahme klären. |
Datenmigration vs. Datenintegration: der Unterschied
Datenmigration und Datenintegration hängen thematisch zusammen, beschreiben aber unterschiedliche Aufgaben. Eine Datenmigration ist in der Regel projektbezogen: Bestehende Daten werden aus einem Quell- oder Altsystem für ein neues Zielsystem vorbereitet und übertragen. Typische Anlässe sind ERP-Wechsel, Shop-Relaunch, PIM-Einführung, CRM-Migration oder die Ablösung bestehender Systeme.
Datenintegration beschreibt dagegen den laufenden Datenaustausch zwischen mehreren Anwendungen. Dabei können Schnittstellen, APIs oder andere technische Verbindungen genutzt werden, damit ERP, Shop, PIM, Warenwirtschaft, CRM oder weitere Systeme im Betrieb Daten miteinander austauschen.
Vereinfacht gesagt: Datenmigration überträgt bestehende Daten in ein neues Zielsystem. Datenintegration verbindet Systeme für den wiederkehrenden Datenaustausch. Beide Themen können innerhalb eines Systemprojekts aufeinander folgen oder parallel relevant werden, unterscheiden sich jedoch in Ziel, Ablauf und zeitlichem Schwerpunkt.
Wenn nach einer Migration mehrere Anwendungen dauerhaft Daten austauschen sollen, ist die Datenintegration eine passende Vertiefung. Eine ausführlichere Gegenüberstellung beider Ansätze finden Sie außerdem im Beitrag Datenmigration vs. Datenintegration.
| Bereich | Datenmigration | Datenintegration |
|---|---|---|
| Ziel | Bestehende Daten aus einem Quell- oder Altsystem in ein neues Zielsystem übertragen. | Mehrere Systeme für einen laufenden Datenaustausch miteinander verbinden. |
| Typischer Zeitpunkt | Bei Systemwechsel, ERP-Wechsel, Shop-Relaunch, PIM-Einführung oder Ablösung bestehender Anwendungen. | Im laufenden Betrieb, wenn mehrere aktive Systeme regelmäßig Daten austauschen sollen. |
| Fokus | Auswahl und Vorbereitung der Daten, Mapping, Transformation, Testmigration, Validierung und finale Datenübernahme. | Schnittstellen, APIs und wiederkehrende Datenflüsse zwischen Anwendungen. |
| Typische Risiken | Unvollständige, ungeeignete oder falsch zugeordnete Daten können in das Zielsystem übernommen werden. | Fehlgeschlagene Übertragungen, nicht abgestimmte Datenflüsse oder unterschiedliche Datenstände können nachgelagerte Prozesse beeinträchtigen. |
| Ergebnis | Die für den Systemwechsel vorgesehenen Daten stehen im neuen Zielsystem für die weitere Nutzung zur Verfügung. | Beteiligte Systeme können im laufenden Betrieb Daten nach definierten Regeln miteinander austauschen. |
Welche Daten migriert werden sollten
Welche Daten in ein neues Zielsystem übernommen werden sollten, hängt vom Projektumfang, von den zukünftigen Prozessen und von den Anforderungen des Zielsystems ab. Nicht jeder Datenbestand aus dem Altsystem muss automatisch migriert werden. Deshalb sollte früh geklärt werden, welche Daten weiterhin aktiv benötigt werden, welche nur historisch relevant sind und welche nicht mehr in das neue System übernommen werden sollen.
Häufig stehen Stammdaten im Mittelpunkt einer Datenmigration: Kunden, Artikel, Lieferanten, Preis- und Konditionsdaten, Produktdaten, Kategorien oder Ansprechpartner. Je nach Projekt können auch Bewegungsdaten, Bestellungen, Belege, Lagerdaten, Historien, Medien, SEO-relevante Daten oder Kommunikationsdaten Teil des Migrationsumfangs sein.
Vor der Migration sollte deshalb für jeden relevanten Datenbereich entschieden werden, ob Daten vollständig übernommen, bereinigt, transformiert, archiviert oder ausgeschlossen werden. Dadurch lässt sich vermeiden, dass veraltete, doppelte oder fachlich nicht mehr benötigte Bestände ungeprüft in das Zielsystem gelangen.
Auch Beziehungen zwischen Daten sollten bei dieser Auswahl berücksichtigt werden. Kunden können mit Ansprechpartnern, Bestellungen oder Konditionen verknüpft sein, Artikel mit Preisen, Kategorien oder Lieferanten und Produktdaten mit Varianten oder Medien. Deshalb sollte nicht nur die einzelne Datenmenge, sondern auch ihre fachliche Bedeutung und ihre Verknüpfung mit anderen Daten im Zielsystem bewertet werden.
| Datenbereich | Typische Beispiele | Wichtige Migrationsfrage |
|---|---|---|
| Kundenstammdaten | Kundennummern, Adressen, Ansprechpartner, Liefer- und Rechnungsadressen, Kundengruppen sowie Konditionen. | Welche Kundendaten werden im Zielsystem weiterhin benötigt und welche Dubletten oder veralteten Datensätze sollten vorab bereinigt werden? |
| Artikelstammdaten | Artikelnummern, Bezeichnungen, Einheiten, Warengruppen, Steuerinformationen, Lagerbezug und weitere Basisdaten. | Wie müssen Artikelstruktur, Nummernkreise, Einheiten und Pflichtfelder für das neue Zielsystem vorbereitet werden? |
| Produktdaten | Produktnamen, Attribute, Varianten, Kategorien, Medien, Beschreibungen, Sprachen und weitere Produktinformationen. | Welche Produktinformationen werden im Zielsystem benötigt und wie sollen bestehende Strukturen übernommen oder angepasst werden? |
| Preis- und Konditionsdaten | Preislisten, Rabatte, Kundengruppenpreise, Einkaufspreise, Gültigkeiten, Währungen und Sonderkonditionen. | Welche Preislogiken, Gültigkeiten und Zuordnungen müssen in die neue Systemlogik überführt werden? |
| Lieferantendaten | Lieferantennummern, Ansprechpartner, Konditionen, Zahlungsbedingungen, Lieferzeiten und Einkaufsinformationen. | Welche Lieferanteninformationen werden für Einkauf, Warenwirtschaft, ERP und weitere Prozesse weiterhin benötigt? |
| Bewegungsdaten und Historien | Bestellungen, Belege, Rechnungen, Lagerbewegungen, Aktivitäten, Kommunikationshistorien oder Projektdaten. | Welche historischen Daten sollen migriert werden und welche können außerhalb des Zielsystems archiviert bleiben? |
Datenqualität und Datenbereinigung vor der Migration
Die Qualität der Ausgangsdaten beeinflusst wesentlich, wie zuverlässig Daten in das neue Zielsystem übernommen und dort weiterverwendet werden können. Werden unvollständige, doppelte, veraltete oder widersprüchliche Daten aus dem Altsystem unverändert übernommen, können bestehende Probleme auch im neuen System erneut auftreten. Deshalb sollte die Datenbereinigung ein fester Bestandteil der Migrationsvorbereitung sein.
Dabei geht es nicht nur darum, einzelne fehlerhafte Werte zu korrigieren. Vor der Übernahme sollte geprüft werden, ob Daten vollständig, eindeutig, konsistent und für die vorgesehene Nutzung im Zielsystem geeignet sind. Auch Formate, Einheiten, Nummernkreise, Kategorien, Preislogiken und Beziehungen zwischen Datensätzen können dabei relevant sein.
Wichtig ist, Daten nicht nur technisch, sondern auch fachlich zu bewerten. Ein Datensatz kann formal gültig sein, aber fachlich veraltet, doppelt oder für das Zielsystem nicht mehr relevant. Datenqualität sollte deshalb immer im Zusammenhang mit den zukünftigen Prozessen und den Anforderungen des Zielsystems betrachtet werden.
Mapping und Transformation ins Zielsystem
Bei einer Datenmigration reicht es häufig nicht aus, Daten aus dem Altsystem zu exportieren und unverändert in das neue Zielsystem zu importieren. Quell- und Zielsystem können sich bei Feldnamen, Datenmodellen, Pflichtfeldern, Formaten, Nummernkreisen, Kategorien oder Beziehungen zwischen Datensätzen deutlich unterscheiden.
Deshalb sollte für relevante Datenbereiche ein nachvollziehbares Mapping definiert werden. Dabei wird festgelegt, welches Feld aus dem Quellsystem welchem Feld im Zielsystem entspricht und wie IDs, Werte und Beziehungen zwischen Datensätzen zugeordnet werden. Das Mapping beschreibt damit, wie die bestehende Datenstruktur auf die vorgesehene Zielstruktur abgebildet wird.
Transformation wird notwendig, wenn eine reine Zuordnung nicht ausreicht. Daten werden dann nach definierten Regeln an die Struktur oder Logik des Zielsystems angepasst. Das kann einfache Formatänderungen betreffen, aber auch komplexere Anpassungen: Kategorien werden neu zugeordnet, Variantenstrukturen verändert, Preislogiken überführt, Kundengruppen neuen Werten zugeordnet oder bestehende Statuswerte in die Logik des Zielsystems übersetzt.
Mapping und Transformation sollten fachliche Anforderungen und technische Zielstrukturen gemeinsam berücksichtigen. Klar definierte Zuordnungen und Transformationsregeln schaffen eine nachvollziehbare Grundlage dafür, die vorbereiteten Daten anschließend in einer Testmigration zu übertragen und die Ergebnisse gezielt zu validieren.
| Aufgabe | Was dabei geklärt wird | Warum es wichtig ist |
|---|---|---|
| Feldmapping | Welche Felder aus dem Altsystem welchen Feldern im Zielsystem zugeordnet werden. | Hilft dabei, Daten nachvollziehbar den vorgesehenen Zielstrukturen zuzuordnen und Abweichungen früh sichtbar zu machen. |
| Formatumwandlung | Wie Datumswerte, Zahlen, Einheiten, Währungen, Telefonnummern, Adressen oder Statuswerte angepasst werden. | Bereitet vorhandene Daten auf die Formate und Verarbeitungsregeln des Zielsystems vor. |
| ID- und Nummernlogik | Wie Kundennummern, Artikelnummern, Lieferantennummern, Belegnummern oder interne IDs behandelt werden. | Hilft dabei, Eindeutigkeit, bestehende Referenzen und Nummernlogiken bei der Übernahme zu berücksichtigen. |
| Beziehungen | Wie Verknüpfungen zwischen Kunden, Ansprechpartnern, Artikeln, Preisen, Kategorien, Bestellungen oder Medien behandelt werden. | Unterstützt dabei, fachliche Zusammenhänge zwischen Datensätzen auch im Zielsystem nachvollziehbar abzubilden. |
| Wertetransformation | Wie bestehende Kategorien, Statuswerte, Kundengruppen, Preislogiken oder Produktattribute neuen Zielwerten zugeordnet werden. | Hilft dabei, Altdaten an Datenmodell, Prozesse und Regeln des neuen Systems anzupassen. |
| Ausschlussregeln | Welche Daten nicht migriert, archiviert oder nur eingeschränkt übernommen werden sollen. | Grenzt veraltete, fachlich nicht mehr benötigte oder ungeeignete Datenbestände vor der Übernahme gezielt ab. |
Testmigration, Validierung und Abnahme
Eine Datenmigration sollte nicht erst bei der finalen Datenübernahme zum ersten Mal unter realistischen Bedingungen durchgeführt werden. Testmigrationen helfen dabei, Mapping, Transformationen, Pflichtfelder, Beziehungen und Anforderungen des Zielsystems vor dem produktiven Einsatz zu überprüfen und Abweichungen frühzeitig sichtbar zu machen.
Bei einer Testmigration werden ausgewählte oder vollständige Datenbestände probeweise in das Zielsystem übernommen. Anschließend lässt sich kontrollieren, ob die vorgesehenen Daten angekommen sind, Feldzuordnungen und Formate passen, Beziehungen korrekt abgebildet werden und die migrierten Daten in relevanten Prozessen genutzt werden können.
Die Validierung bewertet das Ergebnis dieser Übertragung fachlich und technisch. Dazu können Stichproben, Abgleiche zwischen Quell- und Zielsystem, Kontrollen von Pflichtfeldern, Mengen oder Summen sowie ausgewählte Prozess- und Funktionstests gehören. Welche Prüfungen erforderlich sind, hängt von Datenbestand, Zielsystem und Projektanforderungen ab.
Werden bei der Validierung Abweichungen festgestellt, können Mapping, Transformationsregeln oder weitere Migrationsvorgaben angepasst und erneut getestet werden. Definierte Prüfkriterien und eine fachliche Abnahme schaffen anschließend die Grundlage für die Entscheidung, ob die finale Datenübernahme vorbereitet werden kann.
Finale Datenübernahme und Cutover vorbereiten
Nach Testmigration, Validierung und fachlicher Abnahme folgt die Vorbereitung der finalen Datenübernahme. Dabei wird festgelegt, wann die produktive Migration stattfindet, welcher Datenstand übernommen wird und wie mit Änderungen zwischen Testmigration und Go-live umgegangen werden soll.
Ein wichtiger Punkt ist die Abgrenzung des finalen Migrationsbestands. Je nach Projekt kann eine vollständige Neuübernahme erforderlich sein oder es werden nur Daten ergänzt, die seit der letzten Testmigration neu angelegt oder verändert wurden. Auch einzelne Datenbereiche können gezielt nachgeladen werden. Welche Vorgehensweise sinnvoll ist, hängt vom Migrationskonzept und vom Datenstand zum Cutover ab.
Bei voneinander abhängigen Daten sollte außerdem die Reihenfolge der Übernahme berücksichtigt werden. Stammdaten können beispielsweise Voraussetzung für Bewegungsdaten sein, während Preise, Bestände, Belege oder Produktinformationen auf bereits vorhandene Datensätze und Zuordnungen angewiesen sein können.
Zum Cutover gehört deshalb nicht nur die eigentliche Datenübertragung. Ebenso wichtig sind ein abgestimmtes Migrationsfenster, definierte Verantwortlichkeiten und festgelegte Kontrollen unmittelbar nach der Übernahme. Auch der Umgang mit auffälligen, fehlenden oder falsch zugeordneten Daten sollte vor dem Produktivstart geklärt sein.
Datenmigration als Teil von ERP-Wechsel, Shop-Relaunch und PIM-Einführung
Datenmigration ist bei vielen Systemprojekten ein wichtiger Teilbereich, aber nicht mit dem gesamten Wechselprojekt gleichzusetzen. Während die Migration die Auswahl, Vorbereitung und Übernahme bestehender Daten in das Zielsystem abdeckt, umfassen ERP-Wechsel, Shop-Relaunch oder PIM-Einführung weitere fachliche und technische Aufgaben.
Risiken und typische Fehler bei Datenmigrationen
Risiken bei Datenmigrationen entstehen häufig nicht erst bei der technischen Übertragung. Probleme können bereits in der Vorbereitung entstehen, wenn Migrationsumfang, Zielsystemlogik, Verantwortlichkeiten oder Prüfkriterien zu spät geklärt werden. Technisch übertragene Daten sind deshalb nicht automatisch fachlich vollständig oder für die vorgesehenen Prozesse geeignet.
Besonders kritisch sind Entscheidungen, die erst während der Migration getroffen werden. Wenn beispielsweise erst nach Beginn der Umsetzung geklärt wird, welche historischen Daten benötigt werden, wie Zielwerte aufgebaut sind oder welche Beziehungen erhalten bleiben müssen, können Mapping und Transformationsregeln mehrfach angepasst werden.
Auch Tests können ein falsches Bild vermitteln, wenn nur geprüft wird, ob Daten technisch importiert wurden. Erst fachliche Testfälle zeigen, ob beispielsweise Zuordnungen, Beziehungen, Werte und relevante Prozesse mit dem migrierten Datenbestand wie vorgesehen genutzt werden können. Deshalb sollten technische und fachliche Validierung aufeinander abgestimmt sein.
Ein weiterer kritischer Punkt ist der Übergang von der Testmigration zur finalen Datenübernahme. Neue oder geänderte Daten seit dem letzten Testlauf, Abhängigkeiten zwischen Datenbereichen sowie notwendige Kontrollen nach dem Cutover sollten bereits vor dem Produktivstart berücksichtigt werden.
Was beeinflusst Aufwand und Umfang einer Datenmigration?
Aufwand und Umfang einer Datenmigration hängen nicht allein von der Anzahl der zu übertragenden Datensätze ab. Entscheidend sind unter anderem Anzahl und Struktur der Quellsysteme, Qualität und Art der vorhandenen Daten, Unterschiede zwischen Quell- und Zielmodell sowie der erforderliche Mapping-, Transformations-, Test- und Cutover-Umfang.
Eine Migration mit wenigen klar strukturierten Datenbeständen stellt andere Anforderungen als ein Projekt mit mehreren Altsystemen, umfangreichen Historien, unterschiedlichen Datenformaten oder komplexen Beziehungen zwischen Datensätzen. Auch die Frage, welche Daten übernommen, bereinigt, transformiert, archiviert oder ausgeschlossen werden sollen, beeinflusst den Projektumfang.
Wie aufwendig einzelne Schritte werden, lässt sich deshalb erst anhand der konkreten Ausgangssituation bewerten. Nicht jede Datenmigration benötigt denselben Bereinigungs-, Transformations-, Test- oder Cutover-Umfang.
Wie maexware Datenmigration unterstützt
maexware unterstützt Unternehmen bei der Vorbereitung und technischen Umsetzung von Datenmigrationen zwischen bestehenden Quell- und neuen Zielsystemen. Welche Leistungen dabei erforderlich sind, richtet sich nach den vorhandenen Datenbeständen, den beteiligten Systemen und den Anforderungen des jeweiligen Migrationsprojekts.
Zu Beginn werden relevante Datenquellen, Strukturen und Anforderungen betrachtet, um den Migrationsumfang und die notwendige Vorbereitung einzugrenzen. Darauf aufbauend können Daten für die Übernahme vorbereitet, Mapping- und Transformationsregeln definiert und die technische Migration für das jeweilige Zielsystem umgesetzt werden.
Ein weiterer Schwerpunkt liegt auf der kontrollierten Prüfung des Migrationsergebnisses. Testmigrationen schaffen die Grundlage, technische und fachliche Abweichungen vor der finalen Übernahme zu erkennen, Regeln bei Bedarf anzupassen und den vorgesehenen Datenbestand für den Cutover vorzubereiten.
Häufige Fragen zur Datenmigration
Was bedeutet Datenmigration? ▾
Wann ist eine Datenmigration notwendig? ▾
Müssen alle Daten aus dem Altsystem migriert werden? ▾
Was ist der Unterschied zwischen Datenmigration und Datenintegration? ▾
Was bedeutet Mapping bei einer Datenmigration? ▾
Warum sind Testmigrationen wichtig? ▾
Was passiert mit Daten, die sich nach einer Testmigration noch ändern? ▾
Wie unterstützt maexware bei einer Datenmigration? ▾
Datenmigration als Grundlage für einen strukturierten Systemwechsel
Eine strukturierte Datenmigration schafft die Grundlage dafür, bestehende Daten kontrolliert in ein neues Zielsystem zu überführen. Entscheidend ist, Migrationsumfang, Datenqualität, Zielstrukturen und Prüfkriterien frühzeitig zu klären, statt die Datenübernahme auf einen technischen Export und Import zu reduzieren.
Welche Vorbereitung notwendig ist, hängt vom Quellsystem, den vorhandenen Datenbeständen, dem Zielsystem und den Anforderungen des jeweiligen Projekts ab. Ein nachvollziehbar vorbereiteter Migrationsprozess schafft dabei eine bessere Grundlage für Testmigration, Validierung und den anschließenden Cutover.
