End of active support for Qt 5 puts the qmake conversion on the security clock

Removed APIs announce themselves. You compile, and the compiler hands you the list ^[12]. QRegExp gives way to QRegularExpression, containers and string handling change, enums change, and parts of the graphics and multimedia stacks change signature ^[6]. That work is tedious and bounded, and it splits cleanly across whoever owns each file.

A .pro file that has accumulated custom build steps, generated sources, platform conditionals and install rules has no such list. That's the difficulty: no list enumerates the work, and no failing test marks the point where it's finished, so you find out by shipping artifacts on every platform you support and comparing them to the ones you shipped last month. The compiler is the cheapest QA engineer you have for API changes, but build files sit outside what it checks.

For the effort ranking in the guide to transfer to your project ^[4], two things have to be true: your build files carry real logic rather than a target and a source list, and your Qt API surface is narrow. Invert both and the ranking inverts with them. The guide offers no measurement, and it comes from a firm that sells the work, closing with an offer of Qt developers and 15-plus years across Qt 4, 5 and 6 ^[13]. That is an estimate drawn from their client mix. It is still the estimate I would expect from anyone who has owned a cross-platform build, which is why I would plan against it rather than argue with it.

The useful structural fact is that qmake still exists in Qt 6 ^[2]. That breaks the implied dependency chain. Getting patch flow back means compiling and behaving correctly on Qt 6; it does not require CMakeLists.txt. So the version bump and the build conversion can run as separate projects with separate schedules, which is close to what the guide itself says when it tells teams to treat the CMake move as its own workstream ^[4]. The caveat is in the same sentence that gives you the option: documentation and framework investment now sit with CMake ^[2], so qmake on Qt 6 works as a stopgap while the real investment moves toward CMake.

Look at the failure modes the guide names, because they are not distributed the way the engineering work is. Four are listed: underestimating the build conversion, third-party dependencies that are not Qt 6 ready, behavioural changes that compile cleanly, and skipping the final Qt 5 step ^[14]. Only the third is a code defect. The other three are estimation, procurement and sequencing ^[15]. That ratio is the argument for doing the unglamorous parts first: get onto the final Qt 5 release and clear deprecations there with the compatibility helpers ^[7], and audit the dependency graph before anyone opens a header ^[9].

The precondition nobody costs is the test suite. Some changes compile and then behave differently, and only tests and QA catch those ^[10]. If your coverage cannot detect a behavioural change in a module, the incremental approach the guide recommends ^[11] degrades into a big-bang switch with extra steps, because you have no signal per stage. Building that coverage is migration work. Budget it as such.

In my context, an application with a thick .pro file and decent regression coverage, the ordering I would defend at review is: final Qt 5, deprecations cleared, dependencies audited, Qt 6 on qmake, then CMake as a funded project of its own. If your build is thin and your QRegExp footprint is everywhere, the last two swap places.