Migration von Qt5 zu Qt6 — was wirklich passiert

Qt Group sagt "einfacher Migrationspfad". Jedes Team, das migriert hat, sagt etwas anderes. Nicht weil Qt6 schlecht ist — sondern weil Qt5-Projekte 5-10 Jahre Technical Debt angesammelt haben, den die Migration schonungslos aufdeckt.

Wir haben mehrere Migrationen begleitet. Die Muster wiederholen sich: unterschaetzter Build-System-Umbau, ignorierte Deprecation Warnings, fehlende Tests. Die eigentliche API-Migration ist selten das Problem.

Was sich wirklich geaendert hat

Breaking Changes, die in der Praxis relevant sind:

• QList ist jetzt QVector — das Speicherverhalten aendert sich grundlegend
• QRegExp → QRegularExpression — komplett neue API, kein Drop-in-Replacement
• QTextCodec entfernt — UTF-8 ist Standard, Legacy-Encodings brauchen eigene Loesung
• QML: Import-Syntax geaendert, neue Property-Deklarationen mit required
• OpenGL direkt → RHI Abstraction Layer — GPU-Code muss migriert werden
• CMake statt qmake — Build-System muss komplett umgebaut werden

// Qt5: QRegExp
QRegExp rx("(\\d+)-(\\d+)");
if (rx.indexIn(input) != -1) {
    QString first = rx.cap(1);
}

// Qt6: QRegularExpression
QRegularExpression re("(\\d+)-(\\d+)");
auto match = re.match(input);
if (match.hasMatch()) {
    QString first = match.captured(1);
}

// Qt5 qmake
QT += core gui widgets
TARGET = myapp
SOURCES += main.cpp mainwindow.cpp

// Qt6 CMake
find_package(Qt6 REQUIRED COMPONENTS Core Gui Widgets)
target_link_libraries(myapp PRIVATE Qt6::Core Qt6::Gui Qt6::Widgets)

Der versteckte Aufwand

• Build-System Migration (qmake → CMake): 20-40% des Gesamtaufwands. Jedes Target, jede Library, jede Custom-Build-Regel muss uebersetzt werden. Bei Projekten mit komplexen qmake-Logiken ist das ein eigenstaendiges Teilprojekt.
• Deprecated API Cleanup: Qt5 hatte deprecated APIs, die in Qt6 entfernt wurden. Wenn die Compiler-Warnungen jahrelang ignoriert wurden, bricht jetzt alles auf einmal.
• Third-Party Dependencies: Viele Qt5-Plugins und Libraries haben keine Qt6-Version. Ersatz finden oder selbst portieren — beides kostet.
• Testing: Jeder Test muss nach der Migration neu laufen. Erfahrungswert: ~15% werden fehlschlagen, oft an unerwarteten Stellen.
• QML Migration: Import-Pfade, Property-Syntax, Compiler-Integration. Bei grossen QML-Codebasen ein eigenes Teilprojekt.

Migration in der Praxis — Schritt fuer Schritt

Kosten und Zeitrahmen

Reale Bereiche aus realen Projekten — keine Marketing-Schaetzungen:

• Kleines Projekt (<50k LOC): 4-8 Wochen, 15.000-30.000 EUR
• Mittleres Projekt (50-200k LOC): 8-16 Wochen, 30.000-70.000 EUR
• Grosses Projekt (>200k LOC): 16-32 Wochen, 70.000-150.000 EUR

Die Spanne innerhalb jeder Kategorie haengt von der bestehenden Architekturqualitaet ab. Gut strukturierter Code migriert am unteren Ende. Monolithischer Code am oberen.

Trade-offs

• Auf Qt5 bleiben: Risiko: EOL-Sicherheitspatches fallen weg, keine neuen Features, schrumpfender Community-Support. Fuer regulierte Branchen wird fehlender Security-Support zum Compliance-Problem.
• Migrieren: Risiko: Kosten, Zeitplan-Ueberschreitung, Regressionen. Aber: danach steht das Projekt auf einer aktiv gepflegten Basis mit 10+ Jahren Support.
• Neu schreiben: Risiko: deutlich hoehere Kosten, aber saubere Architektur. Realistisch nur bei Projekten, deren Architektur so schlecht ist, dass Migration teurer als Neubau wird.

Empfehlung: Migrieren, wenn <200k LOC und akzeptable Architektur. Bei >200k LOC mit schlechter Architektur einen partiellen Rewrite in Betracht ziehen — die Module mit dem groessten Technical Debt neu bauen, den Rest migrieren.

Ihr AlpiType Team
Landsberg am Lech · alpitype.de