現在、かなりうまく設計された一連のMFCアプリケーションを維持していますが、ユーザーインターフェイスは疲れ始めており、重複やパフォーマンスの問題を解決するために、多くのコードをかなりのリファクタリングする必要があります。独自のすべての描画を処理するかなりの数のカスタムコントロールを使用します（すべてMFCを使用して記述されています）。
最近、私はQtとそれが提供する利点（クロスプラットフォームであり、UI開発のためのより「プロフェッショナル」な外観のフレームワークと呼ばれるものをサポートする）についてさらに調査を行っています。
私の質問は-おそらくQtフレームワークに移行するための最良のアプローチは何でしょうか？QtはMFCでうまく機能しますか？カスタムコントロールの一部をQtに移植し始めて、既存のMFCアプリに徐々に統合する方がよいでしょうか。（これは可能ですか？）
アドバイスや以前の経験をいただければ幸いです。
私の会社では、現在 Qt を使用しており、非常に満足しています。
個人的には、MFC アプリを Qt フレームワークを使用するように移動する必要はありませんでしたが、ここにあなたにとって興味深いものがあります:
これは Qt-Solutions の一部であるため、Qt-Solutions ライセンスと一緒に Qt ライセンスを購入する必要があります。（編集：もうありません）
これが役立つことを願っています！
（これは実際にはあなたの特定の質問に答えるものではありませんが...）私は個人的にQtを使用していませんが、商用のWindows開発には無料ではありません。
無料のwxWindowsを見たことがありますか？ここに素敵な記事があります。余談ですが、すべてのプラットフォームに単一のコードベースが必要な場合は、MFCから移行する必要があるかもしれません。MFCはWindowsのみを対象としていると確信しています（間違っている場合は誰かが修正します）。
もう1つのオプションは、VS2008のSP1でのMFCへの機能パックの更新を確認することです。これには、Officeスタイルのリボンコントロールを含む新しいコントロールへのアクセスが含まれます。
それはトリッキーな問題であり、答えはあなたがどれだけの時間を持っているかに依存しているのではないかと思います。カスタムコントロールをQtに移植すると、はるかに良い結果が得られます。QStyleクラスを使用して実際の描画を行うと、すぐにテーマ化可能なコードが作成されます。
一般的に、私のアドバイスは、弾丸を噛み、一度にすべてを実行することです。確かに、もっと時間がかかるかもしれませんが、別の方法は、十分に機能しないコードをデバッグするために時間を費やし、2つのシステム間のマイナーな非互換性に対処するためにさらに多くのコードを書くことです（そこで、それを行いました）。
要約すると、私のアドバイスは、ブランチを開始し、古いMFCコードをすべて取り除いて、Qtに置き換えることです。プラットフォームに依存しないように（ほぼ）無料で入手できます。しばらく時間がかかりますが、最終的にははるかに優れた製品になります。
警告の最後の言葉：「Qtのやり方」を理解するために時間をかけてください-場合によってはMFCのアプローチとはかなり異なる可能性があります-あなたがしたい最後のことはMFCで終わることです-スタイルQtコード。
私は以前にこの種のことを行うチームを率いていました (MFC から QT ではなく、原則は機能するはずです)。
最初に、ダイアログとその入力、コントロール、および出力が何であるかを文書化しました。また、特に GUI 内の巧妙なロジック用にいくつかのテスト ケースを作成します。
GUI のクリーンなインターフェイスを提供するためにビジネス ロジックをリファクタリングしなければならないこともありましたが、これは最初に行うべきだった方法です。
これで、カプセル化された GUI が一致する必要のある GUI、入力、出力、テスト、およびインターフェイスのリストができました。
プロジェクトごとに、古いものと同等の GUI の作成を開始しました。これが完了したら、古い GUI があった場所に GUI を挿入し、再構築してテストすることができます。最初はよくつまずきましたが、すぐによくあるエラーを解決して修正しました。約 12 人のチームが作業していましたが、612 のダイアログをナビゲートしました (と思います)。