Wenn der SQL Server älter ist als das Notebook

Du weißt, was ich meine:
SQL Server 2008 R2 – läuft ja noch.
SQL Server 2012 – „reicht uns“.

Aber: Kein Support. Keine Sicherheit. Keine Features.
Und irgendwann auch kein Zugriff mehr, weil ODBC-Treiber, Office oder Windows nicht mehr mitspielen.

Spätestens wenn ich eine Migration plane, wird klar, wie viel Risiko da eigentlich steckt.

Warum Du aktualisieren solltest

• Kein Support mehr ab SQL 2016 Standard SP2
• Keine Sicherheitspatches → DSGVO-Risiko
• Keine neuen Features → kein Query Store, kein ADR, kein UTF-8
• Kein aktuelles .NET, kein TLS 1.2+
• Kein Azure-Backup, kein modernes Monitoring

Wenn Du das nächste Mal auf das Eventlog guckst und „Schreibzugriff auf TempDB fehlgeschlagen“ liest, weißt Du, was ich meine.

Meine Migrationsstrategie

Ich arbeite pragmatisch.
Kein Big Bang.
Sondern planbare Schritte.

1. Zielversion festlegen (meist LTS-Version wie 2019 oder 2022)
2. Alt-System per Reporting-Funktionen bewerten
3. Kompatibilitätsprobleme prüfen
4. Testmigration auf Dev-Server
5. Abnahme durch Anwender
6. Umstellung am Stück oder gestaffelt

Schritt 1: Welche Version läuft überhaupt?

SELECT 
    SERVERPROPERTY('ProductVersion') AS Version,
    SERVERPROPERTY('ProductLevel') AS SP,
    SERVERPROPERTY('Edition') AS Edition,
    SERVERPROPERTY('EngineEdition') AS Engine;

Damit weißt Du, wo Du stehst – und was alles fehlt.

Schritt 2: Kompatibilitätslevel prüfen

SELECT 
    name, 
    compatibility_level 
FROM sys.databases;

Kompatibilitätslevel unter 110 (SQL 2012) ist ein Warnsignal.

Schritt 3: Altlasten identifizieren

SELECT 
    OBJECT_NAME(object_id) AS Objekt,
    definition 
FROM sys.sql_modules 
WHERE definition LIKE '%sp_addmessage%'
   OR definition LIKE '%sp_addextendedproc%'
   OR definition LIKE '%RAISERROR % 16%';

Damit findest Du unsaubere Fehlerbehandlung, alte Systemprozeduren, feste Fehlernummern.

Auch wichtig: veraltete Datentypen (text, ntext, image) umstellen.

Schritt 4: Auf Kompatibilität testen

Nutze das Data Migration Assistant (DMA) von Microsoft.
Der scannt Dein System und zeigt, was im Zielsystem Probleme macht.

Beispiel: Alte CLR-Projekte oder eigene Fulltext-Indizes auf deprecated Features.

Schritt 5: Testmigration und Parallelbetrieb

Restore der DB auf neuer Instanz:

RESTORE DATABASE MeineDB
FROM DISK = 'E:\Backup\MeineDB_FULL.bak'
WITH MOVE 'MeineDB_Data' TO 'D:\Daten\MeineDB.mdf',
     MOVE 'MeineDB_Log' TO 'D:\Log\MeineDB.ldf',
     STATS = 10;

Dann Zugriff testen.
Berichte prüfen.
Langläufer vergleichen.

Falls nötig: Kompatibilitätslevel anpassen.

ALTER DATABASE MeineDB
SET COMPATIBILITY_LEVEL = 150; -- für SQL 2019

Schritt 6: Umstellung vorbereiten

• Nachttermin
• Zugriff stoppen (z. B. per Firewall oder DNS)
• Finales Backup
• Restore auf neues System
• DNS oder Verbindungspfad umstellen
• Alte Instanz read-only sichern

Und: Monitoring aktivieren.

Tabelle: Alt vs. Neu – konkret

Mein Setup für stabile Migrationen

Ein SQL Server ist kein Wein. Der wird nicht besser mit der Zeit.

Wer auf 2008 R2 bleibt, spart keine Lizenz – sondern lädt Risiken ein.
Mach’s richtig. Mach’s planbar.
Dann läuft’s auch auf moderner Hardware –
und Du bist raus aus der Support-Hölle.