SQL_Server_Migration_Assistant_Aktualisierte_Ziel-Versionen_Richtung_SQL_2025_un_20260509_1457

SQL Server Migration Assistant: Aktualisierte Ziel-Versionen Richtung SQL 2025 und Azure SQL

Executive Summary

Microsoft hat am 24. April 2026 die offizielle Doku zum SQL Server Migration Assistant (SSMA) auf Stand gebracht. Die Liste der Ziel-Versionen wurde aufgeräumt und atmet jetzt Cloud-Gegenwart: SQL Server 2019, 2022, 2025, Azure SQL Database und Azure SQL Managed Instance. Was wegfällt, wird nicht mehr ausdrücklich beworben – und das ist kein Detail für die Fußnote, sondern ein Signal für dein nächstes Migrationsprojekt.

Parallel rollt seit Februar 2026 SSMA v10.5 aus. Die Version bringt Copilot-gestützte Code-Konvertierung jetzt auch für SAP ASE (Sybase), größere Token-Fenster für Oracle PL/SQL und einen messbaren Stabilitätssprung beim Brennpunkt Azure SQL Managed Instance. Wenn dein Migrations-Runbook noch auf alten Targets, alten Bibliotheken oder alten Faustregeln steht: jetzt updaten, bevor der Cutover-Termin steht. Hinterher noch Annahmen tauschen ist – sagen wir freundlich – karrierelimitierend.

Kurzfassung für den Lenkungsausschuss in einem Satz: Wer 2026 noch eine Migration auf SQL Server 2014, 2016 oder 2017 verspricht, fährt aus dem offiziellen Werkzeug-Korridor heraus und hat im Bug-Fall keinen Microsoft-Hebel mehr.

Abb. 1: SSMA v10.5 – aktualisierte Quell- und Ziel-Matrix mit Copilot-Pfad.

Worum geht es im Detail? Hintergründe und was wirklich neu ist

Der SQL Server Migration Assistant ist seit Jahren das Brot-und-Butter-Werkzeug, mit dem Microsoft Datenbanken aus Fremdwelten auf den eigenen Hof holt. Unterstützte Quellen sind nach wie vor Microsoft Access, IBM Db2, MySQL, Oracle und SAP ASE (früher Sybase). Es ist genau die Liste, die du erwartest, wenn du Bestandskunden betreust, deren Datenbestand zwischen 1998 und 2014 entstanden ist. Pro Quelle gibt es einen eigenen SSMA-Build, jeder mit eigenem Download-Center-Eintrag.

Neu ist die Klarheit auf der Zielseite. In der frischen Doku steht ohne Wenn und Aber: SSMA migriert nach SQL Server 2019 (15.x), SQL Server 2022 (16.x), SQL Server 2025 (17.x) – jeweils Windows und Linux – sowie nach Azure SQL Database und Azure SQL Managed Instance. Ältere Versionen wie SQL 2014 oder 2016 sind aus der offiziellen Aufzählung verschwunden. Das heißt nicht, dass alte Migrationen plötzlich brennen – es heißt, dass dir Microsoft im Supportfall freundlich auf die Doku zeigen wird, wenn du außerhalb des Korridors fischst. Lifecycle ist eine Einbahnstraße, und du sitzt nicht am Steuer.

Im selben Atemzug hat Microsoft im Februar 2026 SSMA v10.5 veröffentlicht. Das ist kein kosmetisches Release. Vier Highlights, die im Projektgeschäft wirklich zählen:

• Copilot für SAP ASE: KI-gestützte Konvertierung von Sybase-T-SQL nach SQL Server und Azure SQL. Microsoft selbst nennt rund 30 Prozent zusätzliche Konvertierungs-Effizienz – praktisch in genau der Schmuddel-Ecke, wo der Auto-Konverter sonst früher die weiße Fahne hisst.

• Copilot für Oracle: Das Token-Fenster für PL/SQL-Eingaben wurde verdoppelt, Output-Tokens sind ebenfalls deutlich gewachsen. Heißt im Klartext: Du musst monströse Oracle-Pakete nicht mehr in Schnipsel zerhacken, bevor du sie an die KI verfütterst.

• Azure SQL Managed Instance: Die SSMA-Erweiterungen, die Oracle-Kompatibilität auf MI absichern, wurden gehärtet. Wer kennt es nicht: Das Ding läuft on-prem auf SQL Server 2019, aber auf MI fliegt dieselbe Stored Procedure mit obskuren Encoding-Faulen. Genau dort hat Microsoft nachgebessert.

• Allgemeine Stabilität: Bugfixes und Verbesserungen über Assessment, Conversion und Monitoring für alle Flavors – Oracle, Db2, MySQL, Access, ASE.

Abb. 2: Versions-Timeline – von SSMA v10.0 bis zum Doku-Update vom 24.04.2026.

Was sind Chancen? Was sind Risiken?

Fangen wir mit den Chancen an, weil das in Lenkungsausschüssen besser ankommt. Die wichtigste: SQL Server 2025 ist offiziell SSMA-Ziel. Das öffnet endlich die Tür für Konsolidierungs-Stories, in denen du "Oracle weg, SQL 2025 hin" nicht mehr handgestrickt rechtfertigen musst. Die zweite: Copilot-gestützte Code-Konvertierung ist erwachsen geworden. Wer in der Vergangenheit ASE- oder Oracle-Migrationen gemacht hat, kennt die Stelle, an der der klassische SSMA kapituliert – genau dort packt der Copilot jetzt zu. 30 Prozent mehr Treffer klingt unspektakulär, aber in einem 4000-Prozedur-Bestand sind das die 1.200 Objekte, die du nicht mehr von einem Senior-Entwickler nachts manuell umschreiben lässt.

Chance Nummer drei: Azure SQL Managed Instance ist ein gangbarerer Landeplatz geworden. Die Oracle-Kompatibilitäts-Krampfanfälle, die du auf MI in der Vergangenheit hattest, sind in v10.5 nachweislich entschärft. Heißt praktisch: Du kannst "Lift, Shift, Modernize" jetzt mit etwas weniger zusammengekniffenen Zähnen verkaufen.

Jetzt die Risiken – und davon gibt es mehr, als der Vertrieb gerne hört. Erstes Risiko: Targets außerhalb der offiziellen Liste. Wer Kunden mit SQL 2014 oder 2016 noch frisch migriert, baut Technical Debt mit Ablaufdatum. Im Audit-Gespräch ist das ein offenes Tor für Beanstandungen.

Zweites Risiko: Source-Versionen. Die Aussage "SSMA kann Oracle" war noch nie ein Blanko-Scheck. Welche Oracle-Releases der jeweilige SSMA-Build wirklich anfasst, steht im Download-Center-Eintrag. Wer das nicht prüft, betritt die uralte Falle "Oracle 11g im Lab funktionierte, 19c in Produktion nicht".

Drittes Risiko: Copilot-Hype. KI-Konvertierung ist gut, aber kein Babysitter. Die generierten T-SQL-Blöcke sehen syntaktisch sauber aus, sind aber gegen deine echten Daten und gegen deine echten NULL-Fälle nicht getestet. Wer den Copilot-Output blind über den Build-Server schiebt, lernt im UAT, was eine Cursor-Semantik wirklich ist – und zwar schmerzhaft.

Viertes Risiko: Tooling-Drift im Team. SSMA v10.0, v10.1 und v10.5 verhalten sich beim Assessment subtil unterschiedlich. Wenn dein Berater-Notebook noch v10.0 hat und der Kunde v10.5 installiert, redet ihr nachweislich aneinander vorbei. Disziplin bei der Werkzeug-Aktualität ist kein Hygienekommentar, sondern Projekthygiene.

Was müssen wir jetzt schon vorbereiten?

Wenn du Kundenprojekte mit Datenbank-Migration in der Pipeline hast, gibt es eine kurze Liste, die du diese Woche durchgehen solltest – nicht nächsten Monat, nicht nach dem Q2-Review.

Erstens: Inventarisiere deine aktuellen SSMA-Installationen. Wer auf v10.0 oder v10.1 unterwegs ist, muss wissen, ob das für das anstehende Projekt ausreicht. Im Zweifel: v10.5 über das Download-Center frisch ziehen (aka.ms/ssmafororacle, aka.ms/ssmaforsybase, aka.ms/ssmafordb2, aka.ms/ssmaformysql, aka.ms/ssmaforaccess). Nichts an alten Mirror-Stores verschwenden.

Zweitens: Validiere die Ziel-Plattform mit dem Kunden. Wer noch SQL 2017 im Servernamen hat, braucht jetzt eine bewusste Entscheidung: SQL 2022 oder gleich auf SQL 2025? Im Zweifel SQL 2022 – mit klarem Update-Pfad auf 2025 später. Und wer ohnehin Cloud denkt: Azure SQL Managed Instance ist mit v10.5 deutlich gnädiger geworden, lohnt also einen zweiten Blick.

Drittens: Bau dir ein Mini-Assessment-Lab. Eine Compose-Datei oder ein Hyper-V-Setup mit der jeweiligen Source-Datenbank, SSMA v10.5 und einem leeren SQL Server 2025 reicht. Dort jagst du den Assessment-Report einmal durch und siehst sofort, wo Copilot hilft und wo manuelles Refactoring nötig wird. Geht in einem halben Tag und schützt dich vor überraschenden Aufwandsschätzungen.

Viertens: Cutover-Termine erst zusagen, nachdem du mindestens einen Probelauf gegen die echten Datenmengen gemacht hast. Klingt banal, ist aber der Punkt, an dem die meisten Projekte später stolpern. Der Assessment-Report ist eine Karte, kein Gelände. Das echte Gelände siehst du erst beim ersten Probelauf – und der dauert bei einem 2-TB-Oracle-Bestand länger, als du im Vertrieb gerne erzählst.

Fünftens: Trainiere deine Berater auf Copilot-Output-Review. Es gibt für "sieht plausibel aus" keinen Prüfstempel – nur für "gegen Testdaten verifiziert". Stelle sicher, dass deine Quality Gates das abbilden: statische Analyse, Plan-Vergleich (Oracle Explain Plan vs. SQL Server Execution Plan) und ein abgenommener Regressions-Testfall pro migriertem Objekt.

Fazit für den Schreibtisch: Die Ansage von Microsoft ist eindeutig. Ziel-Plattformen sind aufgeräumt, KI ist eingewoben, und das Tool ist stabiler als noch vor zwölf Monaten. Wer jetzt sein Migrations-Runbook frisch macht, gewinnt Zeit, Kredibilität und im Zweifelsfall den nächsten Auftrag. Wer wartet, wartet auf das Q3-Audit – und das ist erfahrungsgemäß kein liebliches Gespräch.