Migrating from Qt5 to Qt6 — what really happens

Qt Group calls it a "simple migration path". Every team that has migrated says something else. Not because Qt6 is bad — but because Qt5 projects have accumulated 5-10 years of technical debt, and the migration exposes it mercilessly.

We have accompanied several migrations. The patterns repeat: an underestimated build-system rebuild, ignored deprecation warnings, missing tests. The actual API migration is rarely the problem.

What has really changed

Breaking changes that matter in practice:

• QList is now QVector — memory behaviour changes fundamentally
• QRegExp → QRegularExpression — completely new API, no drop-in replacement
• QTextCodec removed — UTF-8 is the default, legacy encodings need their own solution
• QML: import syntax changed, new property declarations with required
• Direct OpenGL → RHI abstraction layer — GPU code has to be migrated
• CMake instead of qmake — the build system has to be rebuilt completely

// 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)

The hidden effort

• Build-system migration (qmake → CMake): 20-40% of the total effort. Every target, every library, every custom build rule has to be translated. For projects with complex qmake logic this is a sub-project of its own.
• Deprecated API cleanup: Qt5 had deprecated APIs that were removed in Qt6. If the compiler warnings were ignored for years, everything breaks at once now.
• Third-party dependencies: Many Qt5 plugins and libraries have no Qt6 version. Find a replacement or port it yourself — both cost.
• Testing: Every test has to run again after the migration. Rule of thumb: ~15% will fail, often in unexpected places.
• QML migration: Import paths, property syntax, compiler integration. For large QML codebases a sub-project of its own.

Migration in practice — step by step

Cost and time frame

Real ranges from real projects — not marketing estimates:

• Small project (<50k LOC): 4-8 weeks, EUR 15,000-30,000
• Medium project (50-200k LOC): 8-16 weeks, EUR 30,000-70,000
• Large project (>200k LOC): 16-32 weeks, EUR 70,000-150,000

The range within each category depends on the quality of the existing architecture. Well-structured code migrates at the lower end. Monolithic code at the upper end.

Trade-offs

• Staying on Qt5: Risk: EOL security patches stop, no new features, shrinking community support. For regulated industries, missing security support becomes a compliance problem.
• Migrating: Risk: cost, schedule overrun, regressions. But: afterwards the project stands on an actively maintained base with 10+ years of support.
• Rewriting: Risk: significantly higher cost, but a clean architecture. Realistic only for projects whose architecture is so poor that migration costs more than a rebuild.

Recommendation: Migrate if <200k LOC and the architecture is acceptable. At >200k LOC with poor architecture, consider a partial rewrite — rebuild the modules with the largest technical debt, migrate the rest.