Kompatibilität prüfen

Ein neues System steht selten allein. Es soll mit bestehender Hardware zusammenarbeiten, auf einem bestimmten Betriebssystem laufen, mit anderen Anwendungen Daten austauschen und in eine bestehende Netzwerk-Topologie passen. Diese Verträglichkeit zu prüfen, ist eine eigenständige Disziplin: die Kompatibilitätsprüfung. Sie passiert nach der Machbarkeitsanalyse und vor dem Rollout. Wer hier oberflächlich arbeitet, entdeckt Probleme erst beim Live-Betrieb – und das kostet ein Vielfaches dessen, was eine systematische Vorab-Prüfung gekostet hätte. Diese Lektion zeigt dir die Ebenen der Kompatibilität, wie man sie methodisch abklopft und welche Testarten dabei eingesetzt werden.

1) Die fünf Ebenen der Kompatibilität

Kompatibilität betrifft nicht eine einzelne Eigenschaft, sondern mehrere Schichten. Jede muss separat geprüft werden, denn ein Mangel auf einer Ebene kann durch Stärken auf anderen nicht kompensiert werden. Klick durch:

Kompatibilitäts-Ebenen – Klick eine Schicht

Daten & Protokolle (CSV, XML, REST, SOAP, JSON)

Anwendung (Software, Versionen, Add-Ons, Plug-ins)

Laufzeitumgebung (.NET, Java, Python, Treiber)

Betriebssystem (Windows/Linux, Version, Architektur)

Hardware (CPU, RAM, Storage, Schnittstellen)

Reihenfolge der Prüfung: von unten nach oben. Eine inkompatible Hardware (z. B. x86 statt ARM) macht jeden OS-Test sinnlos. Eine fehlende .NET-Laufzeit macht jede App-Installation überflüssig. Manche Schichten lassen sich überspringen, wenn die Lösung als Container oder SaaS kommt – dann liegt die untere Schicht beim Anbieter.

2) Kompatibilitäts-Matrix – das Werkzeug für den Überblick

In komplexen Umgebungen mit vielen Anwendungen, Betriebssystemen und Datenbanken hilft eine systematische Kompatibilitäts-Matrix. Sie macht auf einen Blick sichtbar, welche Kombinationen unterstützt sind und wo Lücken bestehen:

Beispiel-Kompatibilitätsmatrix für ein ERP-Update

Komponente	Win 10	Win 11	Server 2019	Server 2022	Ubuntu 22
ERP Client v8.x (alt)	✓	⚠	–	–	✗
ERP Client v9.x (neu)	✓	✓	–	–	⚠
ERP Server v9.x	–	–	⚠	✓	✓
SQL Server 2016	–	–	✓	⚠	✗
SQL Server 2022	–	–	✓	✓	✗
Office 2019	✓	⚠	–	–	–
Office 365	✓	✓	–	–	–
.NET 4.8 Runtime	✓	✓	✓	✓	⚠

Legende: ✓ voll unterstützt · ⚠ eingeschränkt / mit Workaround · ✗ nicht unterstützt · – irrelevant. Diese Matrix wird vom Hersteller bereitgestellt (zertifizierte Kombinationen) oder vom Projektteam erstellt. Wichtig: nur „zertifizierte" Kombinationen sind im Supportfall hilfreich. Wer auf gelben Feldern arbeitet, riskiert „Support not available" wenn etwas schief geht.

3) Quellen für Kompatibilitäts-Informationen

Wo bekommt man verlässliche Kompatibilitätsangaben? Mehrere Quellen sollten kombiniert werden – keine ist allein vollständig:

Hersteller-Dokumentation: Die offizielle Systemvoraussetzungen-Seite jeder Software ist die Hauptquelle. Achte auf „supported" vs. „certified" – nur certified ist im Supportfall belastbar.
Hardware Compatibility List (HCL): Speziell bei Servern, Hypervisoren (VMware, Hyper-V) und spezialisierter Hardware listet der Hersteller geprüfte Kombinationen.
Release Notes: Wichtige Hinweise auf entfallene Unterstützung („Deprecated") oder neue Voraussetzungen kommen in jedem Release. Vor Upgrade pflichtlektüre.
Knowledge Base / Foren: Erfahrungsberichte anderer Anwender – wertvoll für „funktioniert in der Praxis" jenseits der offiziellen Liste.
Eigene Tests: Letzte Wahrheit. Was im Lab läuft, läuft auch in Produktion (sofern das Lab realistisch ist).
Reverse-Engineering / API-Doku: Bei Eigenentwicklungen oder Schnittstellen-Integrationen muss man oft selbst herausfinden, welche Versionen/Felder wie zusammenspielen.

Goldene Regel: Vertraue keiner einzigen Quelle blind. Hersteller schreiben gern „supported", auch wenn die Kombination kaum getestet ist. Foren-Beiträge sind oft veraltet. Eigene Tests übersehen Edge Cases. Drei unabhängige Bestätigungen für eine kritische Kombination = solide Basis.

4) Test-Arten in der Kompatibilitätsprüfung

Kompatibilitätsprüfung heißt: testen. Dabei kommen mehrere Test-Arten zum Einsatz, jede mit ihrem Fokus:

Test-Arten in der Kompatibilitätsprüfung

Smoke Test

Schneller Grundcheck: läuft die Anwendung überhaupt? Startet das Login? Antworten die wichtigsten Funktionen? 10-15 Minuten, gibt erstes Lebenszeichen.

Funktionstest

Alle relevanten Funktionen durchspielen. Eingabemasken, Berechnungen, Reports, Exporte. Idealerweise mit Testfall-Katalog aus dem Pflichtenheft.

Regressionstest

Beim Update / Upgrade: Bleibt alles Alte weiterhin funktional? Häufig durch automatisierte Test-Suites. Mehr in Regression Test.

Performance / Last-Test

Bringt das System die geforderte Leistung unter realistischer Last? Tools: JMeter, k6, Locust. Wichtig für Anforderungen wie „1000 gleichzeitige Nutzer".

Sicherheits-/Vuln.-Test

Schwachstellen-Scans (Nessus, OpenVAS), Pen-Test, Container-Image-Scans. Pflicht für jede Produktivumgebung.

Akzeptanztest (UAT)

Endanwender prüfen das System gegen das Lastenheft. „Funktioniert es so, wie wir es brauchen?" Mehr in Übergabe und Abnahme.

Wichtig: Diese Test-Arten ergänzen sich, sie ersetzen sich nicht. Ein perfekter Funktionstest schützt nicht vor Performance-Problemen. Ein guter Last-Test deckt keine Sicherheitslücken auf. Für jede Kategorie sollten klare Erfolgskriterien vorab definiert sein – sonst gibt es am Ende endlose Diskussionen, was als „bestanden" gilt.

5) Test-Umgebungen aufbauen

Kompatibilitätstests gehören nicht in die Produktion. Stattdessen braucht es dedizierte Test-Umgebungen, die produktionsähnlich sind, aber niemanden gefährden. Übliche Stufung:

Umgebung	Zweck	Charakteristik
Dev (Entwicklung)	Entwickler bauen und probieren	Schnell wechselnd, kleine Datenmengen, oft Testdaten
Test / QA	Funktions- und Regressionstests	Stabil über Tage, vollständige Testdaten
Stage / Pre-Prod	Letzte Generalprobe	1:1 wie Produktion (Hardware, Daten, Konfiguration). Echte Schnittstellen.
Prod	Echtbetrieb	Live-Daten, echte Nutzer. Keine Experimente!

Idealerweise sind diese Umgebungen durch Infrastructure as Code reproduzierbar – ein Setup-Skript baut Stage genauso auf wie Prod. Snapshots und Docker Compose sind hier ideale Werkzeuge. Wichtig: Testdaten dürfen keine echten personenbezogenen Daten sein – oder zumindest pseudonymisiert. Mehr in DSGVO-Grundprinzipien (Zweckbindung).

6) Typische Kompatibilitäts-Stolpersteine

Aus jahrelanger IT-Praxis ein paar Klassiker, die in fast jedem Migrationsprojekt auftauchen – damit du sie vorab auf dem Schirm hast:

32-Bit-vs-64-Bit: Eine alte 32-Bit-Anwendung läuft auf einem 64-Bit-OS in der Regel – braucht aber Kompatibilitätsbibliotheken (auf Linux: multilib, auf Windows: WoW64). Treiber jedoch müssen passend zur OS-Architektur sein.
Zeichenkodierung: Eine UTF-8-Datei wird auf einem Windows-System mit Latin-1-Erwartung gelesen → Umlaute werden zu „M├╝ller". Häufig bei CSV-Importen und Datenbank-Migrationen.
Datum und Zeit: US-Format (MM/DD/YYYY) vs. ISO (YYYY-MM-DD) vs. deutsch (DD.MM.YYYY). Zeitzonen, Sommerzeit, Schaltsekunden. Excel rechnet Datum als Tage seit 1.1.1900 (mit Bug für 29.2.1900).
Dezimaltrennzeichen: 1,5 vs. 1.5 vs. 1 500,00 vs. 1,500.00. CSV-Imports laufen ständig in diese Falle.
Endianess und Encoding: Bei Binärformaten / Protokollen: Big-Endian vs. Little-Endian, Network-Byte-Order. Eher in Embedded/Industrie relevant.
Lizenz-Inkompatibilität: Software kombiniert GPL-Code mit kommerziellem Code → Lizenzkonflikt. Mehr in Open-Source-Lizenzen.
Performance-Falle „Cloud": SaaS-Lösung scheint langsam – nicht wegen der Cloud selbst, sondern weil zwischen DB (im Haus) und Anwendung (in der Cloud) jede Abfrage 100 ms Netzwerk-Latenz kostet. Datenlokalität ist kritisch.
Browser-Inkompatibilität: Webanwendung läuft mit Chrome, aber nicht mit Safari oder Firefox – fehlende Polyfills, andere CSS-Interpretation. Cross-Browser-Tests sind Pflicht.

7) Dokumentation und Freigabe

Die Ergebnisse der Kompatibilitätsprüfung gehören schriftlich festgehalten. Inhalte:

Geprüfte Kombinationen: Komplette Matrix mit Ergebnissen.
Testfallergebnisse: Was wurde getestet, was ist bestanden, was nicht?
Bekannte Einschränkungen: Was funktioniert nicht oder nur mit Workaround?
Empfehlung: Geht das System in den Rollout, mit welchen Hinweisen?
Risiko-Bewertung: Was kann im Live-Betrieb noch passieren?

Auf Basis dieses Berichts gibt der Auftraggeber die Freigabe für den nächsten Schritt – oder ordnet Nachbesserungen an. Bei kritischen Mängeln ist eine Freigabe „unter Auflagen" möglich: das System geht live, aber bestimmte Funktionen sind deaktiviert oder werden in einer Folgeversion ergänzt. Mehr in Warum IT-Dokumentation? und Aufbau der Projektdokumentation.

Zusammenfassung

Eine Kompatibilitätsprüfung erfolgt nach der Machbarkeitsanalyse und vor dem Rollout. Geprüft wird auf fünf Ebenen: Hardware (CPU, RAM, Schnittstellen), Betriebssystem (Versionen, Architektur), Laufzeit/Treiber (.NET, Java, Python, Hardware-Treiber), Anwendung (Konflikte mit installierter Software, Browser-Anforderungen), Daten & Protokolle (Formate, Encoding, REST/SOAP). Prüfung von unten nach oben. Werkzeug: Kompatibilitäts-Matrix mit Komponenten × Umgebungen, Status (✓/⚠/✗). Quellen: Hersteller-Doku, HCL, Release Notes, Knowledge Base, eigene Tests – drei unabhängige Bestätigungen für kritische Kombinationen. Test-Arten: Smoke (schneller Grundcheck), Funktion (alle Use Cases), Regression (Altes weiterhin funktional), Performance (Last), Sicherheit (Vuln-Scan), Akzeptanztest (Endanwender). Test-Umgebungen: Dev → Test/QA → Stage → Prod. Stage muss 1:1 wie Prod sein. Klassische Stolpersteine: 32/64-Bit, UTF-8 vs. Latin-1, Datumsformate, Dezimaltrennzeichen, Lizenzkonflikte, Browser-Differenzen, Cloud-Latenz bei verteilten Datenquellen. Ergebnisse schriftlich dokumentieren und vom Auftraggeber freigeben lassen.