Zu Beginn der Datenbankmigration analysieren wir gründlich die bestehende Datenbankumgebung. Dazu gehören die Version der Datenbank-Engine, das Datenbankschema, gespeicherte Prozeduren, Trigger, Datenvolumen, Replikation sowie die Abhängigkeitsanalyse der Anwendungen. Aufgrund dieser Analyse erstellen wir einen Migrationsplan mit Zielplattform, Migrationsstrategie (homogen oder heterogen), empfehlende Tools, Risikobewertung und einem phasenbasierten Zeitplan. Diese Beratung kann vor der eigentlichen Migration als eigenständiger Prozess erfolgen.
Bei der homogenen Migration werden Datenbanken innerhalb derselben Datenbankplattform, jedoch zwischen unterschiedlichen Versionen, migriert, zum Beispiel von SQL Server 2012 zu SQL Server 2022 oder von PostgreSQL 10 zu PostgreSQL 16. Dazu gehören Upgrade-Planung, Kompatibilitätstests, Migration von Schema und Daten, Tests der gespeicherten Prozeduren sowie das Cutover. Diese Art der Migration ist in der Regel risikoärmer, erfordert jedoch eine sorgfältige Behandlung veralteter Funktionen und geänderter Standardeinstellungen.
Hier erfolgt die Migration von einem Datenbanksystem zu einem anderen, zum Beispiel von Oracle zu PostgreSQL, von Microsoft SQL Server zu Amazon Aurora oder von IBM DB2 zu MySQL. Der Prozess umfasst die Konvertierung des Datenbankschemas und der Datentypen, die Anpassung von gespeicherten Prozeduren und Triggern, Anpassung der Datenbankabfragen sowie die Validierung der Daten nach der Migration. Aufgrund unterschiedlicher SQL-Dialekte, Indexierungsstrategien und Transaktionsmechanismen ist der Zeitaufwand höher als bei homogenen Migrationen.
Wir unterstützen Unternehmen bei der Migration lokaler Datenbanken in Cloud-basierte Lösungen wie Amazon RDS, Amazon Aurora, Azure SQL, Azure Database for PostgreSQL oder MySQL, Google Cloud SQL oder Cloud Spanner. Dazu gehören der Aufbau der Cloud-Infrastruktur, Netzwerkkonfiguration, Sicherheitsmaßnahmen, Migration mit minimaler Ausfallzeit sowie die Anpassung der Verbindungseinstellungen der angebundenen Anwendungen.
In diesem Prozess wird ein Data Warehouse von einem klassischen On-Premise-System auf eine cloud-basierte Datenanalyse-Plattform wie Amazon Redshift, Google BigQuery oder Azure Synapse Analytics übertragen. Das Data Warehouse kann auf Oracle Exadata, Teradata oder SQL Server Analysis Services basieren.
Im Rahmen der Migration führen wir eine Restrukturierung des Datenbankschemas durch. Dazu gehören Normalisierung oder Denormalisierung entsprechend den Anforderungen der Zielplattform, Aufteilung großer Tabellen, Anpassung der Indexstruktur sowie das Entfernen überflüssiger oder nicht genutzter Objekte. Dieser Schritt ist erforderlich, wenn das bestehende Schema auf der Zielplattform ohne Anpassungen nicht optimal funktioniert.
Wir entwickeln oder migrieren ETL-Pipelines, die für den Transfer, die Transformation und das Laden von Daten aus den Quellsystemen in die Zielumgebung dienen. Dazu gehören Batch- und Streaming-ETL mit Technologien wie Apache Kafka, AWS Glue, Azure Data Factory, Apache Airflow und dbt. Bei mehreren Quellsystemen und komplexen Transformationsprozessen wird die ETL-Pipeline als eigenständiger Prozess im Gesamtprojekt umgesetzt.
Für Systeme mit hohen Verfügbarkeitsanforderungen wird während der Migration eine Datenreplikation zwischen Quell- und Zielsystem eingerichtet. Die Anwendung wird auf die Zieldatenbank umgestellt, sobald die Replikationsverzögerung fast null erreicht. Eine Rollback-Option steht zur Verfügung, bis die Quelldatenbank endgültig außer Betrieb genommen wurde.
Nach dem Go-live kontrollieren wir die Leistung der Datenbanken auf der Zielplattform, beheben Leistungsprobleme bei Abfragen und passen Indexe sowie Connection-Pool-Einstellungen an. Der Support erfolgt auf Retainer-Basis mit definierten Antwortzeiten gemäß SLA.
Die Migration von den Datenbanken der Patienteninformationssysteme und elektronischen Gesundheitsakten erfordert eine sorgfältige Durchführung in allen Projektphasen. Dazu gehören Datenverschlüsselung gemäß HIPAA-Vorgaben während Migration und Speicherung sowie die Validierung von Zugriffsrechten vor der finalen Umstellung.
Bei Core-Banking- und Transaktionsdatenbanken sind Datenkonsistenz und Ausfallsicherheit entscheidend. Vor der Deaktivierung des Quellsystems prüfen wir gründlich die Transaktionsintegrität und regulatorische Anforderungen.
Produktinformationsdatenbanken und Datenbanken für Auftragsverwaltung werden auf die neue Plattform übertragen, wobei eine stabile Leistung auch zu Spitzenzeiten sichergestellt wird. Drittanbietersysteme wie Payment-Gateways, Lagerverwaltungssysteme und Marketingtools werden vor und nach der Umstellung getestet.
Abrechnungs- und Kundendatenbanken im Telekommunikationsbereich verarbeiten große Datenmengen und erfordern hohe Verfügbarkeit. Kontinuierliche Replikation und ein schrittweiser Cutover sorgen dafür, dass das Quellsystem aktiv bleibt, bis das Zielsystem stabil funktioniert.
ERP- und MES-Datenbanken enthalten wichtige Informationen wie Produktionspläne, Stücklisten und Anbindungen an die Produktion. Vor Beginn der Migration wird eine umfassende Analyse der Systemabhängigkeiten durchgeführt.
Datenbanken für Sendungsverfolgung und Flottenmanagement werden in cloud-basierte Umgebungen migriert, die eine native Unterstützung für Datenaufnahme und -verarbeitung bieten. Latenz und Durchsatz werden auf der Zielplattform vor Beginn der Migration geprüft.
Datenbanken für Content-Metadaten und Rechteverwaltung werden in cloud-basierte Umgebungen übertragen, die für analytische Abfragen optimiert sind. Während der Abnahmephase wird die native Unterstützung anhand der bestehenden Reporting-Workloads getestet.
Persönliche Daten der Studenten und ihre Bewertungsdaten werden unter Berücksichtigung strenger Datenschutzanforderungen migriert. Integrationen mit LMS-Systemen und weiteren Tools werden in einer Staging-Umgebung geprüft, bevor das Produktions-Cutover erfolgt.
