Qt Migration From Qt 5 to Qt 6

What does a Qt migration with bitshift cover?

We take on the whole path from Qt 5 to Qt 6 – or exactly the stage where it is currently stuck.

• Effort assessed up front through a time-boxed spike, with named items rather than a flat rate
• Modernization on Qt 5.15 with deprecation warnings cleared – the most effective and most frequently skipped stage
• Moving the build from qmake to CMake as a separate, independently verifiable step
• The switch to Qt 6 with Qt5Compat as a bridge, followed by retiring the transitional dependencies
• Replacing what was removed – Qt Quick Controls 1, modules rewritten for Qt 6 such as Qt Multimedia, QRegExp and QTextCodec
• Graphics stack and platform plugin verified on the target, not only in the desktop build
• A safety net of automated tests, on request through our Embedded Testrack on real hardware

Why does the migration come up at all?

The pressure rarely comes from a support calendar. It almost always comes from hardware.

Qt 5.15 was the last Qt 5 version with long-term support; its open-source support has ended and commercial terms change over the years – check the current state directly with The Qt Company. The actual trigger, though, is usually a new SoC: it brings a newer Yocto release, which brings a newer compiler and newer system libraries, and at some point an old Qt 5 no longer builds cleanly inside it. Waiting until then means migrating under time pressure alongside a board bring-up. That is the most expensive possible order.

How does the migration run?

In five stages, each of which stays runnable on its own – the most common misstep is switching Qt version, build system and compiler at the same time.

Stage	Work	Result
1	Move to Qt 5.15, clear deprecation warnings	Running application free of outdated calls
2	Move the build to CMake – still on Qt 5	Build change verified in isolation
3	Switch to Qt 6 with Qt5Compat as a bridge	First running Qt 6 version
4	Retire Qt5Compat, move QML to versionless imports	No transitional dependencies left
5	Validate graphics stack and platform plugin on target	Confirmed behaviour on the real device

Because a working state exists after every stage, any failure that appears has only one plausible cause. The technical background is covered at length in our article on migrating from Qt 5 to Qt 6.

What do embedded targets add?

On the desktop a migration ends at a green build. On a device that is where the real test starts.

In Qt 6, Qt Quick no longer renders directly against OpenGL but through the RHI, an abstraction over each platform’s graphics API. On the desktop this is barely noticeable. On a board with EGLFS, a vendor-specific EGL and a GPU driver whose quirks the team has learned over years, that is exactly where the time goes. Then there is the BSP: the Qt 6 layer has to match the board’s Yocto release, and jumping several Yocto releases drags kernel, toolchain and system libraries along. How we build and maintain such layers is described under Yocto BSP & distributions.

The difference from a pure Qt shop: because we already own the embedded Linux platform underneath, the BSP question is part of the engagement for us rather than an interface at which responsibility ends.

What does a Qt migration cost?

A defensible number only exists after the spike – before that it would be a guess.

Four questions drive the effort. How much QML is there, and does it depend on Qt Quick Controls 1? Does the application use modules that were rewritten for Qt 6, Multimedia above all? How idiosyncratic is the target hardware’s graphics stack? And do automated tests exist that would make a regression visible at all? We settle that in a first step of contained size and then put an assessment with named items in front of you. You decide on that basis whether and how far it continues.

Why bitshift dynamics for your Qt migration?

Because the Qt knowledge and the embedded depth come from the same team.

We have worked on hardware-near software since 2005 and cover C++, Qt/QML, embedded Linux and Yocto together – which is why a migration with us does not get stuck at the graphics stack or the BSP. We are based in Lörrach on the German-Swiss-French border, work remote-first and on-site across the DACH region when needed, in German and in English. If your team would rather carry out the migration themselves, that works too: we then come along as a sparring partner, or through a matching training.