Why migrating?

Migrating from Microsoft Foundation Class (MFC) to Qt can offer several advantages, here are some reasons to consider:

Cross-platform compatibility: Qt is a well-known cross-platform toolkit, that allows writing code once and deploys across multiple platforms such as Windows, macOS and Linux,
Modern look'n feel: Qt style follows all modern user interface guidelines, and provides by default a style very close to the native one on any supported platform
Modern and intuitive API: Qt provides a modern and intuitive API, and leverages modern C++ features,
Flexible and customizable: Qt offers a lot of flexibility and customization options, adapting to new UI paradigms (like touch-screens),
Integration with modern technologies: Qt integrates well with modern technologies such as OpenGL, Web, and QML (Qt Modeling Language) for creating fluid and interactive user interfaces,
Active support: Qt is largely supported by The Qt Company and the community at large, and provides commercial support options for companies that need it. Qt is also continually evolving and adapting to new technologies and industry trends,
Active community: Qt has a large and active community of developers, making it easier for new developers to learn Qt or for companies to hire Qt developers

Before starting a migration, it's important to understand the main reason(s) behind the migration, it could be one or several of those:

the MFC library is not supported anymore,
the UI feels outdated and needs a refresh,
the application needs to run on multiple platforms,
the application needs to support new UI paradigms (touch screens…),
it’s getting harder to add new features, fix bugs (technical debt),
it’s getting harder to find good MFC developers.

‍Note: Beyond the technical aspect, it's important for the team to have training and support during the transition.

What to migrate?

One of the nice aspects of an MFC to Qt migration is that the overall architecture and business logic of the application can stay the same. MFC-specific code will be replaced with equivalent Qt classes and APIs, with some adaptation but without any major refactoring needed.

To do a full migration of the code, there are 4 main areas to migrate:

The user interface: migrating the dialogs and UI elements to their Qt equivalent
The build system: moving away from MSBuild to a more modern and platform-independent build system (CMake is the norm these days)
Business logic code: migrating all the core MFC classes (like CString) to pure C++ or Qt equivalent, this step will require touching most of the code
Windows APIs: to be multi-platform, all Windows-specific APIs need to be replaced with OS-generic equivalents, or be specific to Windows using #ifdef

Depending on the main reasons for the migration, some of the areas to migrate could be unnecessary or postponed. For example, if the result application will continue to be Windows-only, it's not necessary to migrate the business logic or Windows API usage.

It is however important to finish the migration of one area once started.

How to migrate?

To do an MFC to Qt migration, you have in general 2 very different solutions:

migrate everything to an equivalent Qt code
create an external library to replace the full MFC API, with 100% coverage

The first solution requires a lot of effort, as most of the code has to be changed in one way or another. The second solution (if such a library would exist) means that you end up basically with the same MFC code making it hard for any Qt developers to read and extend.

The KDWinUtils library seats between the 2 solutions:

it has classes to replace some part of MFC, with a compatible API (for example KString replaces CString)
it still allows Qt developers to use the Qt API (KString is a QString)
high-level concepts (like message maps or data exchange) are migrated to Qt

Goals:

provides Qt-compatible classes with an API close to the MFC API
allows MFC developers to still read and improve the code
allows Qt developers to use and leverage the full Qt API
reduces the changes needed for migration

Non-goals:

provides a 100% compatible and comprehensive MFC API
requires no changes or rewrites of the application