Hohes Risiko, aber geringer Aufwand – oder doch XL-Umfang? Was kostet eine Datenmigration?

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

Fujitsu Technology Solutions GmbH

Nexus Industrial Memory

Die Frage, wie viel Geld für eine Datenmigration benötigt wird und wie dies geschehen soll, erfolgt zumeist vergleichsweise spät in einem mehrstufigen Prozess. Dr. Andy Martens teilt den Aufwand, der in verschiedenen Stadien getrieben werden muss, nach T-Shirt-Größen ein.

Soll in einem Unternehmen ein neues System in Betrieb genommen werden, wird ein mehrstufiger Prozess eingeleitet. Die Erfahrung zeigt, dass die Auswahl des neuen Systems, das Customizing und nicht zuletzt der Veränderungsprozess im Unternehmen im Vordergrund stehen. Etwas später fällt auch ein, dass die Daten ebenfalls in das neue System migriert werden müssen. Unmittelbar danach stellt sich die Frage, wie viel Geld dafür benötigt wird und wie dies geschehen soll.

Die Frage des zusätzlichen Budgets hängt stark mit dem Umfang und der Komplexität der Datenmigration zusammen. Ähnlich sind jedoch die Aktivitäten, die in Datenmigrationsprojekten immer wieder durchgeführt werden müssen. In diesem Beitrag geben wir einen Überblick über die üblichen Aktivitäten mit einer Aufwandsabschätzung auf der Basis von T-Shirt-Größen.

Die Historientiefe

Die erste Phase enthält in der Regel die Definition von Daten, die in das Zielsystem migriert werden müssen und die andererseits in ein Archiv übertragen werden sollen. Man spricht in diesem Zusammenhang von der Historientiefe. Sie bestimmt, wie „jung“ die Daten sein müssen, um für das operative Geschäft noch wichtig zu sein. Diese müssen in das Zielsystem migriert werden, während andere archiviert werden können.

Die Historientiefe hat einen starken (fast linearen) Einfluss auf den Aufwand im Gesamtprojekt. Darüber hinaus hängt der Arbeitsaufwand stark vom Umfang und der Komplexität der Datenstrukturen, der Datenqualität und insbesondere davon ab, wie unterschiedlich die Datenstrukturen in Quell- und Zielsystem sind. Hier würde ich den Aufwandswert „L“ vergeben.

Big Bang oder inkrementelle Migration?

In der zweiten Phase geht es um die strategische Planung und Konzeption der Datenmigration. Sollen die Daten in einem Zug (Big-Bang-Migration) oder inkrementell migriert werden? Wie steigt das Unternehmen auf das neue System um? Ebenfalls mit Big Bang oder inkrementell? Darf es Downtime-Zeiten geben, wie groß dürfen diese sein, und wann soll die Migration überhaupt stattfinden?

Anschließend wird hier die Erstellung eines Cut-over-Plans (oder eines Migrationsdrehbuchs) in Auftrag gegeben und vorbereitet. Der Aufwand wird hier mit „M“ gut abgeschätzt sein.

Datenbereinigung

Ein großes Risiko in Datenmigrationsprojekten stellt die schlechte Datenqualität dar. Gute Datenqualität ist fast eine Ausnahme. Wir empfehlen daher, in dieser Phase eine Datenbereinigung einzuplanen. Sie wird später „S“ Euro kosten.

Die Definition der Transformationsregeln, die in Abstimmung mit den Fachabteilungen des Unternehmens erfolgen sollte, und die Implementierung der ETL-Strecken (ETL = Extraction, Transform, Load) sind zweifellos die kostenintensivsten Aktivitäten. Es werden nicht nur die (externen) IT-Experten eingesetzt, sondern es werden in der Regel auch bereits gut ausgelastete Fachexperten des Unternehmens benötigt.

Das Hauptziel ist hier, die Daten aus dem Quellsystem so zu transformieren, dass die Geschäftsprozesse im neuen System mit den migrierten Daten reibungslos ablaufen und zu den gleichen Ergebnissen wie im alten System führen. Wenn zwei Unternehmen fusionieren, müssen auch die Daten zusammengeführt werden. Das bedeutet etwa, dass Dubletten identifiziert und behandelt werden müssen.

Geplante Downtime

Wenn die Downtime-Fenster geplant sind, muss der Performance der Migrationsprogramme viel Aufmerksamkeit gewidmet werden. Der Aufwand ist hier mit der Größe „XL“ abzuschätzen. Wie bereits erwähnt, gibt es auch den „S“-Aufwand für die Aufbereitung und Bereinigung der Daten.

Hervorzuheben ist auch, dass vor der/den Live-Migration(en) auch permanent Testläufe durchgeführt werden müssen. Die Qualitätssicherung sollte während der gesamten Entwicklung kontinuierlich erfolgen. Sie spiegelt die Bereitschaft der Migration wider.

Nicht zu vergessen sind hier die Testdaten. Man sollte möglichst heterogene Testdaten beschaffen, um eine breite Testabdeckung zu erreichen. Produktivdaten in Tests zu verwenden, ist natürlich ein No-Go. Pseudonymisierung, Anonymisierung und Differential Privacy sind hier die Schlüsselworte.

Test, Test, Test ...

Performance-Tests zur Messung von Laufzeiten sind für die Planung von Downtime-Fenstern (falls vorgesehen) entscheidend. Die Infrastruktur und die Läufe selbst sind nicht besonders teuer, aber sie nehmen viel Zeit in Anspruch. Hier sollte man so viel wie möglich automatisieren. Die Kosten für die Vorbereitung, Durchführung und Auswertung der Testergebnisse würde ich mit „L“ veranschlagen.

Nicht zuletzt ist die Live-Migration zu nennen. Wenn man sich entschieden hat, die Daten inkrementell zu migrieren, müssen mehrere Live-Migrationen durchführt werden. In solchen Momenten wird das gesamte Unternehmen in Alarmbereitschaft versetzt. Es werden Bereitschaftszeiten vereinbart, Notfall- oder Rollback-Pläne erstellt.

Unbedingt erforderlich ist hier die Entscheidungsgrundlage für die Projekt- und Unternehmensführung. Prüfkennziffer, automatisierte Tests, aber auch fachliche Stichproben sind die Grundlage, auf der über die Inbetriebnahme des neuen Datenbestandes entschieden wird. Hier bezahlt man eher mit den Nerven. Aufgrund der kurzen Zeiten ist das Kostenniveau eher auf dem „S“-Level.

Datenmigration, wie jedes Business-Change- und IT-Transformationsprojekt, kann zu einem Risiko oder gar einem Problem werden, muss es aber nicht. Offene Augen, gesunder Menschenverstand, erfahrene Experten und ein wenig Glück ermöglichen in der Regel eine erfolgreiche, qualitativ hochwertige Datenmigration.

*Der Autor: Dr. rer. nat. Andy Martens studierte Informatik und promovierte anschließend 2018 an der Universität Duisburg-Essen. Er war mehrere Jahre bei der Adesso SE als IT-Berater mit den Schwerpunkten Datenanalyse und Datenmanagement tätig. Im Jahr 2020 gründete er in Hamburg das Unternehmen Qurix Technology.

Sein Team ermöglicht den Kunden, Daten in neue IT-Plattformen wie DWH und Cloud zu bewegen. Der Schwerpunkt liegt dabei auf dem Schutz personenbezogener Daten. Im Jahr 2020 hat er zudem eine Arbeit als Lehrbeauftragter an der Universität Hamburg aufgenommen.

(ID:46383848)