Datenmigration, schleichende Migration und Datenmitnahme

Im folgenden Beitrag stellen wir euch das Anwendungsbeispiel einer Datenmitnahme in einer Web-Plattform vor. Zusätzlich zählen wir euch Anwendungsbeispiele für eine Datenmigration und schleichenden Datenmigration auf. Was eine Datenmigration ist, wieso eine Datenmitnahme weniger Risiken mit sich bringt und wie eine schleichende Migration, verläuft findet ihr in unseren Beiträgen "Braucht es immer eine Datenmigration?" Teil 1 und Teil 2.

Datenmitnahme oder -Migration, Illustration

Datenmitnahme mit einer Web-Plattform

Das Unternehmen Pond ist fest in der Industrie verankert. Über die letzten Jahre entstand die Datenbank PondBase mit über 100.000 relevanten Daten für den Unternehmensgegenstand. Die Bestandsanwendung PondBottom ist das Herzstück der Firma Pond und importiert, verarbeitetet und exportiert die Daten vom Speichersystem PondBase und kann somit alles, was das Unternehmen braucht, zentral auf einer Anwendung. Da die Anwendung zu Gründungszeiten entwickelt wurde und zu diesem Zeitpunkt nicht ersichtlich war, welchen Umfang die Anwendung annehmen wird, ist diese nicht mehr zeitgemäß und verliert über die Jahre an Performanz. Durch die großen Datenmengen und zahlreiche Wechsel der Prozesse, Workflows und Mitarbeitenden müssen zukünftige Workflows und Prozesse zuerst an die Kommunikation zwischen PondBase und PondBottom angepasst werden. Die Anwendung PondBottom erleidet durch die Datenmengen eine Drosselung der Performance und die Mitarbeitenden müssen mit hohen Ladezeiten bei Datenabfrage rechnen.

Beurteilung des Ist-Zustands

Durch die hohen Datenmengen kommt es häufig vor, dass die Daten beim Verschieben innerhalb der PondBase im System verschwinden und nicht mehr ausfindig gemacht werden können. Der Datenverlust wird zunächst meist nicht bemerkt, bis die Anwendung PondBottom eine Fehlermeldung anzeigt. Die Daten zu suchen, wiederherzustellen oder neu anzulegen, kostet den mitarbeitenden Zeit und muss meist händisch nachgepflegt werden. Die Prozesse und Workflows werden erzwungen pausiert. In manchen Fällen erkannte das System das Fehlen der Daten zu spät und ganze Workflows mussten neu gestartet werden. Die IT rät zu einer Datenumstrukturierung der internen Infrastruktur. Doch eine Migration von Daten bedarf einen genauen Datenmigrationsplan, kostet Zeit und Ressourcen und wird zunächst von der Geschäftsleitung mit großen Bedenken abgelehnt. Nach einigen Recherchen stößt die IT der PondBottom auf den externen Dienstleister DevDuck GmbH und erfährt, dass eine Datenmitnahme mit einer Web-Plattform möglich ist ohne Datenmigration der PondBase. In einem kurzen Gespräch wird entschieden, dass PondBottom neu entwickelt werden soll. Die Anforderungen an das neue PondBottom 2.0. sind unter anderem, dass jederzeit eine Erweiterung möglich sein soll und die Daten von PondBase verarbeitet werden können.

Erste Schritte

Bevor überhaupt an eine Anwendung oder Datenmigration gedacht wird, erstellt DevDuck gemeinsam mit der Firma Pond eine Bestandsaufnahme des Bestandssystems und dessen Komponenten. Das bedeutet eine Auflistung mit allen Systemen, Servern, Workflows und Prozessen. Aus dieser Auflistung wird der Prozess der vorhandenen Daten ersichtlich und daraus kann abgelesen werden, welche Systeme wiederverwendet, erweitert oder abgelöst werden können. Bei diesem Prozess erkennen viele Unternehmen wie Pond, dass über die Jahre viel zusammen gekommen ist und niemand mehr genau wusste, welche Komponenten zu den Prozessen zugeordnet sind und wie vernetzt die Abhängigkeiten der Systeme über die Jahre geworden sind. Anschließend wird der Kern der Anwendung identifiziert und ein Abhängigkeitsgraf über die Vernetzung mit den benötigten Daten und Systemen erstellt.

Bestandsanwendung 2.0.

Basierend auf den gesammelten Daten und Analyse von DevDuck, entscheiden sich beide Unternehmen gegen eine Datenmigration und für eine Datenmitnahme. In diesem Fall entwickelt DevDuck eine neue Anwendung PondBottom 2.0 ohne Datenmigration. Die neue Anwendung beinhaltet zunächst den zuvor analysierten Kernprozess des alten Systems. Die Daten werden von der PondBase bei Abruf importiert und innerhalb PondBottom 2.0. mit einem Konnektor im System transformiert. Somit werden die Daten in der Datenbank nicht manipuliert und die Ladezeiten des Systems verkürzen sich, da sich die neuen Daten direkt in der Anwendung befinden. Das führt zu einer Performancesteigerung gegenüber des alten Systems. Über einen längeren Zeitraum wird PondBottom 2.0 ausgebaut und löst somit PondBottom ab. Ein weiterer Vorteil der Anwendung ist auch, dass jederzeit ein neuer Konnektor entwickelt werden kann, um mit verschiedenen Datenbanken kommunizieren zu können. Der stück für Stück Nachbau des Systems wird durch die modulbasierte Entwicklung ermöglicht. Somit können die benötigten Komponenten und Workflows jederzeit eingebunden oder ausgetauscht werden. Die Prozesse müssen nicht stagnieren und werden bei der Neuentwicklung gleichzeitig automatisiert und optimiert.- alles zentral auf einer Plattform.

Sollte das Unternehmen Pond sich in der Zukunft für eine Cloud-Anbindung entscheiden, kann ein neuer Konnektor entwickelt werden und direkt mit der Cloud kommunizieren. Durch den Konnektor muss somit nicht ein neues System entwickelt werden, sondern das bestehende System kann weiterhin verwendet werden.

Schleichende Datenmigration

Die positive Zusammenarbeit mit DevDuck ermutigt die Geschäftsleitung, auch die PondBase in PondBase 2.0 zu ändern. Dies soll mittels schleichender Migration geschehen. Die Vorteile einer schleichenden Migration sind, dass bei der Übertragung von Daten sowie das Bereinigen von Daten kein Datenverlust droht. Zusätzlich werden alte Daten nicht migriert, sondern verbleiben auf der PondBase. Der Verlauf der schleichenden Datenmigrationen verläuft nach folgender Checkliste:

Die neue Datenbank PondBase 2.0. wird eingeführt
PondBottom 2.0. überprüft bei jeder Datenabfrage im System, ob die Daten in PondBase 2.0. existieren.

Wenn Ja, dann werden die Daten aus dem neuen System PondBase 2.0. abgerufen und abgespeichert
Wenn Nein, werden die Daten aus PondBase abgerufen, über PondBottom 2.0. transformiert und in das Zielsystem PondBase 2.0. abgespeichert.

Die Datenbank PondBase 2.0. ist nun die zentrale Datenbank für PondBottom 2.0.

Mit diesem Prozess werden alle relevanten Daten automatisiert im Zielsystem hinterlegt und PondBase wird abgelöst. Ohne Migrationssoftware oder direkter Kommunikation zwischen beiden Datenbanken können Daten verschoben werden und die Integrität ihrer Daten wird nicht beeinflusst.

Datenmigration

Da das Unternehmen Pond für 2023 eine Kosteneinsparung geplant hat, soll die IT eine der beliebtesten Arten der Datenmigration vornehmen - die Cloud-Migration. Hierbei wird von der Bestandsdatenbank die Daten in eine Cloud migriert. In diesem Fall entschied sich das Unternehmen Pond für eine Public Cloud eines Drittanbieters. Die Übertragung von Daten in die Cloud übernimmt ein Drittarbeiter. Dieser erstellt einen Datenmigrationsplan und migriert die Datensätze aus dem Quellsystem in die Cloud. Diese Art der Migration wird bei Unternehmen immer beliebter, da eine hohe Kosteneinsparung im Gegenzug zu eigenen Rechenzentren entsteht. Der Migrationsprozess muss stetig überwacht werden und kann zu Ausfallzeiten in einigen Prozessen führen. Durch das Migrieren der Daten in die Cloud findet im Unternehmen eine digitale Transformation der Daten statt. Dies führt Unternehmen einen Schritt näher zur Industrie 4.0.

Best Practices

Mit der Web-Plattform PondBottom 2.0. konnten nun alle vorherigen Probleme und zeitintensiven Prozesse nicht nur behoben werden, gleichzeitig findet eine Prozessoptimierung und Automatisierung statt. Das neue Bestandssystem ist flexibel und kann durch die modulbasierte Entwicklung sich jedem Workflow und Prozess anpassen. Das Unternehmen erfährt dadurch eine Kosten-, Zeit- und Ressourceneinsparung und eine erhöhte Produktivität durch automatisierte Prozesse und schnellere Datenabfragen.