Datenbankmigration mit KI: Code und Daten umziehen, ohne dass Fehler still durchrutschen
In diesem zweitägigen Seminar setzt du KI bei einer Datenbankmigration so ein, dass sie Arbeit spart, ohne neue Fehler einzuschleppen. Eine KI übersetzt Prozeduren und Abfragen in Sekunden. Sonderfälle übersetzt sie aber mit derselben Sicherheit falsch, und solche Fehler fallen oft erst Wochen später in den Zahlen auf. Das Seminar führt von der Bestandsaufnahme über das Übersetzen und den Datenumzug bis zum Nachweis, dass beide Datenbanken dasselbe liefern. Ausgangssysteme sind Oracle, SQL Server, DB2, Informix, Sybase und MS Access, Ziel ist PostgreSQL oder SQL Server.
Unverbindlich anfragen — wir melden uns mit einem passenden Termin oder Inhouse-Angebot.
Warum eine Übersetzung, die läuft, noch keine Migration ist
Die übersetzte Prozedur lässt sich anlegen, der Test läuft grün, die Anwendung startet. Trotzdem kann sie anders rechnen als vorher: Eine leere Zeichenkette ist in Oracle NULL, in PostgreSQL und SQL Server nicht. Datumsarithmetik, Rundung und Groß- und Kleinschreibung verhalten sich je System anders. Solche Unterschiede melden keinen Fehler, sie verändern still das Ergebnis.
Das Seminar setzt deshalb nicht beim schnellen Übersetzen an, sondern bei der Frage, woran du erkennst, was die KI nicht verstanden hat, und wie du am Ende nachweist, dass alte und neue Datenbank dasselbe liefern.
Für wen ist dieses Seminar
Für Datenbankadministratorinnen und -administratoren, Datenbankentwicklerinnen und -entwickler sowie Verantwortliche für Migrationsprojekte, die eine bestehende Datenbank nach PostgreSQL oder SQL Server überführen und dabei KI einsetzen wollen. Das Angebot richtet sich an Unternehmen, Behörden und öffentliche Einrichtungen, Vereine und Verbände sowie Selbstständige.
Was du mitbringen solltest
Gute SQL-Kenntnisse und Erfahrung mit dem Ausgangssystem. Vorkenntnisse im Zielsystem und mit KI sind hilfreich, aber nicht nötig.
Geschult wird auf der jeweils aktuellen Version; bei Inhouse-Seminaren gern auch auf der Version, die ihr im Einsatz habt.
Detaillierte Inhalte
Zwei aufeinander aufbauende Tage mit Übungen an einer vorbereiteten Ausgangsdatenbank mit Prozeduren, Triggern und Sichten. Bei Inhouse-Seminaren richten sich Ausgangs- und Zielsystem nach eurem Projekt.
Bestandsaufnahme vor der ersten Übersetzung
- Hunderte Prozeduren, Trigger und Sichten: Was gibt es überhaupt, und was davon wird noch benutzt?
- Wo stecken die Abhängigkeiten, die beim Umzug zuerst brechen?
- Welcher Code darf in ein Cloud-Modell, und was bleibt im Haus?
Übersetzen mit KI
- Die KI übersetzt in Sekunden – woran erkennst du, was sie nicht verstanden hat?
- Seltene Sonderfunktionen: Warum liegt die KI gerade dort am selbstsichersten falsch?
- Eine Prozedur nach der anderen oder alles auf einmal: Wie groß darf ein Auftrag an die KI sein?
- Gleiche Aufgabe, zweiter Lauf, anderes Ergebnis: Wie wird die Übersetzung wiederholbar?
Dialektfallen, die still durchrutschen
- Leere Zeichenkette und
NULL: in Oracle dasselbe, in PostgreSQL und SQL Server nicht - Datumsarithmetik, Zeitzonen und Rundung: gleicher Ausdruck, anderes Ergebnis
- Groß- und Kleinschreibung bei Namen und Vergleichen
- Transaktionen, Sperren und Fehlerbehandlung in Prozeduren: Was verhält sich nach dem Umzug anders?
- Typumwandlungen, die das Ausgangssystem stillschweigend erledigt hat
Daten umziehen
- Datentypen ohne genaue Entsprechung: Was geht beim Übertragen verloren?
- Zeichensätze und Sonderzeichen: Warum heißt Herr Müller plötzlich anders?
- Große Tabellen und kurze Wartungsfenster
Nachweisen, dass es stimmt
- Liegen nach der Migration in beiden Datenbanken wirklich dieselben Daten?
- Die übersetzte Prozedur läuft fehlerfrei – liefert sie auch dasselbe Ergebnis?
- Wer prüft die Tests, die die KI zu ihrer eigenen Übersetzung geschrieben hat?
Anwendungen und Betrieb
- SQL in der Anwendung, im Bericht, im Ladeprozess: Was übersieht eine Migration, die nur die Datenbank betrachtet?
- Rollen, Rechte und zeitgesteuerte Jobs
- Dieselbe Abfrage ist nach dem Umzug langsamer: Woran liegt das?
- Ziel PostgreSQL oder SQL Server: Was ändert sich an Datentypen, Prozedursprache und Betrieb?
Hinweis: Inhalte und Tiefe passen wir bei Inhouse-Seminaren an euer Ausgangssystem und euren Bestand an.
- Praxis statt Frontalvortrag — kurze Erklärung, dann übst du selbst an einer echten Ausgangsdatenbank.
- Eigener Bestand willkommen — bei Inhouse-Seminaren arbeiten wir auf Wunsch an einem Ausschnitt eurer Datenbank.
Dauer: 2 Tage · Durchführung: remote oder inhouse bei euch – deutschlandweit, in Österreich und der Schweiz
Was du danach kannst
- Den Bestand einer Datenbank vor der Migration erfassen und Abhängigkeiten erkennen, die beim Umzug zuerst brechen
- Prozeduren und Abfragen mit KI übersetzen und erkennen, wo die Übersetzung nicht stimmt
- Dialektfallen wie leere Zeichenkette und NULL, Datumsarithmetik oder Groß- und Kleinschreibung gezielt prüfen
- Daten mit passenden Datentypen und Zeichensätzen umziehen
- Nachweisen, dass alte und neue Datenbank dieselben Daten und Ergebnisse liefern
- Anwendungen, Berichte, Rollen und Jobs in die Migration einbeziehen
Verwandte Seminare
Die Besonderheiten eines Ausgangssystems in voller Tiefe behandeln die Migrationsseminare nach PostgreSQL:
- PostgreSQL Migration von Oracle
- PostgreSQL Migration von Microsoft SQL Server
- PostgreSQL Migration von DB2
- PostgreSQL Migration von Informix
- PostgreSQL Migration von Sybase
- PostgreSQL Migration von MS Access
Dazu passt:
- KI & Vibe-Coding für SQL und Datenbanken — Schema-Entwurf, Tuning und KI-Agenten mit Datenbankzugriff.
Dein Dozent
Frank Glück schult seit mehr als 30 Jahren und programmiert seit 1986. Seit 1999 ist er auch als Dozent für die GFU tätig.
Häufige Fragen (FAQ)
Ersetzt dieses Seminar die Migrationsseminare für ein bestimmtes Ausgangssystem?
Nein. Dieses Seminar zeigt den Einsatz von KI über die ganze Migration, herstellerübergreifend. Die Besonderheiten eines Ausgangssystems in voller Tiefe behandeln die Migrationsseminare von Oracle, SQL Server, DB2, Informix, Sybase und MS Access nach PostgreSQL.
Welche Ausgangssysteme werden behandelt?
Oracle, SQL Server, DB2, Informix, Sybase und MS Access als Ausgangssystem, PostgreSQL oder SQL Server als Ziel. Bei Inhouse-Seminaren richten wir uns nach eurem Projekt.
Darf unser Code in ein Cloud-Modell?
Das hängt davon ab, was im Code steckt. Im Seminar geht es darum, was ohne Bedenken übergeben werden kann, was nicht, und wann ein lokales Modell im eigenen Haus die bessere Wahl ist. Was im Einzelfall erlaubt ist, klärt ihr mit eurem Datenschutzbeauftragten.
Was kostet die Teilnahme?
Der Preis richtet sich nach Format, Umfang und Teilnehmerzahl — gerne auf Anfrage.