Datenbank-Migration: Fünf mögliche Fallstricke

Die Umstellung auf eine neue Datenbank ist ein komplexer Prozess mit vielen Unwägbarkeiten. Der vorliegende Artikel nennt die fünf häufigsten Hürden, auf die bei der Datenbank-Migration geachtet werden sollte.

Eine Datenbank-Migration ist ein komplexer Prozess, bei dem einige Fallstricke drohen. (Bild. Pixabay.com)

Die Anforderungen an aktuelle IT-Infrastrukturen sind klar umrissen: Sie müssen schnell, agil, skalierbar und hochverfügbar sein. Legacy-Systeme, wie etwa relationale Datenbankmanagement-Systeme (RDBMS), sind damit aufgrund ihrer Strukturen überfordert. Sie sind zu starr und begrenzt, um die benötigten Daten und Informationen für moderne, verteilte Anwendungen in Hybrid-IT- und Multi-Cloud-Szenarien bereitstellen zu können. Die Migration auf eine flexible Datenbank-Plattform, die die Vorteile von RDBMS, NoSQL und Cloud mit Edge Computing beherrscht, erscheint daher logisch und zwingend. Dahinter verbergen sich jedoch Teilaspekte, die großer Beachtung bedürfen, um solch einen zeitgemäßen Wechsel möglichst sauber und risikoarm vorzunehmen. Gemäss Couchbase, einem Anbieter einer modernen Datenmanagementplattform, sind es fünf Fallstricke, die bei einer Datenbank-Migration lauern:

  1. Die Migration der Daten. Es ist fatal, beim Umstieg auf eine neue Datenbank (wie NoSQL) das Datenmodell des alten relationalen Datenbankmanagement-Systems 1:1 zu übernehmen. Um die Vorteile moderner Datenbanken richtig zu nutzen und neue Use Cases und SLAs (Service Level Agreements) unterstützen zu können, bedarf es eines neuen Datenmodells – so wie ein Sportwagen adäquate Reifen braucht, um sein ganzes Potenzial zu entfalten.
  2. Die Migration des App-Frameworks. Gleiches gilt für die Applikations-Logik. Das Programmier-Framework muss an die Möglichkeiten der neuen Datenbank angepasst werden. Das betrifft beispielsweise die Adaption der Programmier-Libraries (SDKs) an die neue Datenbank. Wenn das nicht ausreicht, weil das Framework im Legacy-System nicht mehr zeitgemäß ist (zum Beispiel Cobol), muss das komplette Framework ausgetauscht werden.
  3. Die Migration der Apps. Ein häufig gemachter Fehler ist der Big-Bang-Ansatz. So wie es wenig sinnvoll ist, mit einem frisch erworbenen Sportwagen umgehend auf Zeitenjagd auf dem Nürburgring gehen zu wollen, sollte auch das Migrationsrisiko durch sukzessives Vorgehen minimiert werden. Eine schrittweise Migration mit bi-direktionalem Data Connector zwischen alter und neuer Welt nimmt den Zeitdruck und gewährleistet, dass der reguläre Betrieb aus Anwendersicht ungestört weiterlaufen kann.
  4. Die Wichtigkeit von Migrations-Partnern. Reine Inhouse-Lösungen gelten oft als vermeintlicher Qualifikationsnachweis, sind aber meist illusorisch. Die Einbeziehung von externer Beratung mit wertvollem Wissen über Best Practices und typische Fehlerquellen kann vor Irrwegen schützen, den Migrationsprozess verkürzen und damit letztlich auch helfen, die Kosten im Griff zu behalten. Diese Erfahrung kann von IT-Systempartnern oder dem Datenbank-Hersteller beigesteuert werden.
  5. Die organisatorischen Veränderungen. Die technische Migration des Datenbank-Systems allein reicht in der Regel nicht, um die angestrebte Unterstützung der Unternehmensziele zu erreichen. Dafür sind auch interne betriebliche Änderungen notwendig, wie beispielsweise eine stärker DevOps-getriebene Organisation. Das verändert auch die klassische Rolle der Datenbank-Administratoren, die stärker in die App-Entwicklung mit Microservices und CI/CD-Automatisierung eingebunden werden.

„Die Datenbank-Migration ist Teil eines umfassenden Modernisierungsprozesses der IT-Infrastrukturen“, erklärt Steffen Schneider, Head of Solutions Engineering Central Europe bei Couchbase. „Unternehmen sollten dies als Chance begreifen, sich technisch und organisatorisch, aber auch vom Mindset her neu aufzustellen und damit ihre Wettbewerbsfähigkeit zu sichern.“

Quelle und weitere Informationen: Couchbase

(Visited 62 times, 1 visits today)

Weitere Beiträge zum Thema