Planning a Qt 5 to Qt 6 migration without stopping delivery

Qt 5 reached the end of its standard support, and many teams now face the same question: how do we move to Qt 6 without freezing feature work for months?

1. Start with an inventory

Before touching code, list what you actually depend on:

• Qt modules in use (some were removed or moved to Qt 5 Compat)
• Third-party libraries built against Qt 5
• Build system — Qt 6 favours CMake over qmake

2. Make the Qt 5 build "Qt 6 ready"

Most of the work can happen on Qt 5.15 first. Enable deprecation warnings and fix them:

target_compile_definitions(app PRIVATE
    QT_DISABLE_DEPRECATED_BEFORE=0x050F00)

Every warning fixed here is one less surprise later.

3. Port module by module

Keep a dual build (Qt 5 and Qt 6) in CI for a while. Port leaf modules first, then work up the dependency graph. The product stays shippable at every step.

4. Measure after the switch

Qt 6 changed the graphics stack (RHI). Profile startup time, memory and rendering on your real targets — especially embedded ones.

A migration is a good moment to pay down technical debt — but only the debt that blocks you. Scope creep is the main reason migrations stall.

Need a migration assessment? Talk to us.