현재 회사에서 서비스하고 있는 3년 정도 된 MFC 프로그램이 있습니다.
내부 UI는 모두 미리 디자인된 jpg 이미지로 버튼,배경들이 그려지고 있습니다만 요구사항이 프로그램 지원 해상도가 FHD 고정이니 다른 여러 해상도(4k모니터 등)를 지원할 수 있게끔 최대해상도에 따라 화면이 커지고 늘어졌으면 하는게 내용입니다.
기존 MFC로 처리하려면 UI가 그려지는 모든 화면에 대한 좌표를 연산식으로 바꿔야 하는 작업인데 나름의 욕심으로는 C# WPF로 넘어가고 싶습니다.
그런데 많은 코드 양과 일정 협의 문제를 안고서라도 Migration 하면 좋을까요??
참고로 mfc 4년차고 wpf는 작은 프로그램들을 3~4개 정도 연습삼아 만들어 봤습니다.
그리고 해당 솔루션은 지속적으로 업데이트 하면서 서비스를 하고 있어 장기적으로도
좋을거 같기도하고 고민이 많네요 ㅠㅠ
MFC 4년차라고 하시니 잘 할 수 있고 편한 것을 선택하면 될 것 같아요.
그렇지만 제 개인적으로는 UI를 MFC로 다루는 것보단 WPF가 좋을 것 같아요.
지속적으로 업데이트를 한다고 하셨으니 언제 어디서 새 UI 요소를 요구할 지 모르기 때문입니다.
그런데 혹시 모르니 다른 직원분들과 상의하고 결정하는게 좋을 것 같아요. 
mfc 로 만들어진걸 UI업데이트를 위해서 WPF로 변경하는건 추천하기 어렵네요.
일단 MFC로 만들어진거면 코어 부분 갈아업는것부터가 일일거고요.
Windows Forms면 모를까 WPF쪽에서는 포팅이 번거로운 API들이 많이 존재 합니다.
UI단이야 빠르게 끝나겠지만 여기저기 트러블 많이 생길 겁니다.
저도 그 부분이 가장 걱정입니다. UI뿐만 아니라 내부 로직까지 다 c# 으로 포팅해야하는데… 언제하나 싶긴 하네요 ㅎㅎ;;
제가 이쪽 분야의 전문가 아니라서 이런 질문을 할 수 있는데요,
기존 핵심 로직 부분은 C++에서 dll로 만들고
그래픽 내지는 시각적인 부분만 WPF로 이식하면 안 되는 걸까요?
interop 내지는 CLI 이식 작업 비용이 배로 많이 들려나요?
저도 해보진 않아서 이식 작업 비용이 얼마나 들지는 모르겠습니다.
다만 핵심 로직을 제외하고더라도 다양한 기능들이 제공되고 있었다 보니 그게 오히려 양이 더 많네요.
그리고 UI도 단순 버튼,표, 배경 뿐 아니라 이미지를 확대/축소/분할/Drawing 등 이미지 편집 기능들이 들어가 있어 그 부분도 WPF로 잘 해낼수 있을지도 고민입니다.
그거 생각보다 노가다 입니다.
interop 의 경우 전부다 C스타일로 API로 뽑아야 해서요.
클래스 사용이 어렵죠.
두번째로 CLI의 경우도 API호환성이 안좋습니다. C++인데. C++이 아닙니다.
특히 저같이 모던C++을 많이 사용할 경우 매우 노가다가 필요해집니다.
이미지 편집까지 필요하면 또하나의 문제가 기본 설정으로는 WPF는 모든 컨트롤에 안티알리아싱이 걸리는데. 보여지는거랑 저장했을때랑 아마 많이 틀려질겁니다.
또 퍼포먼스나 메모리 측면에서 많이 안좋아지고요.
만약 3D랜더링이나 동영상 재생 같은 기능이 들어가 있으면 WPF는 완전 비추입니다.
특히 동영상 재생쪽이 아주 쥐약입니다.
제 의견으로는…
장기적으로 유지할 제품이라면 C++ & MFC를 떠나는게 좋다고 생각합니다…
현시대에서 C++은 gui aplication 작성에 별로 효과적이지 못한 언어인거 같습니다.
(물론 MFC도…)
@도깨비 제 개인적인 의견으로는 꼭 WPF 시도해보셨으면 좋겠습니다. 
저도 MFC, Winform, Xflatform 등의 윈도우 프로그램을 WPF로 새로 만드는 작업을 경험했는데요. 고생도 많이 했지만 그만큼 남는 것도 많았던 것 같습니다.
이미 WPF를 연습 삼아 하셨으니 멋진 시작이 될 것 같습니다!
(그리고 리스크를 검토하기 위해 개인 프로젝으로 먼저 진행하시는 것도 좋을 것 같아요.)
개인적으로는 MFC에서 WPF로 무리해서 재개발을 하는 것 보다는, C++/CLI로 확장하시는 것이 좀 더 좋은 선택이 아닐까 생각합니다.
이 방식을 추천드리는 이유는, C++로 시작한 애플리케이션은 C++로 계속 유지 관리하는 것이 여러모로 생산성, 코드 유지 관리에 도움이 되기 때문이라고 생각합니다.
대략 어떤느낌인지 알 것 같기도하네요.
우선 간단한 프로젝트부터 해보면서 제가 감당할 수준인지 파악해보는게 먼저겠네요. WPF는 하고싶지만 회사일이고 괜한 스트레스로 다가올까봐 걱정했던게 사실입니다.
여러모로 막막했는데 의사결정에 큰 도움이 될 것 같습니다!
C++/CLI 는 생각지도 못한건데 알아봐야겠군요~ 감사합니다.
의사 결정에 도움이 되셨다고 하니 기쁩니다. 글을 읽다가 좀 더 생각나서 몇 가지 의견을 더 드려보려고 합니다.
만약 애플리케이션이 장기적으로 리눅스 데스크톱, 맥 OS 데스크톱까지 지원을 확대할 계획이 있으시다면 @SangHyeon.Kim 님의 말씀처럼 될 가능성이 높습니다. 하지만 윈도우 데스크톱 기반의 애플리케이션으로 계속 남을 예정이라면, 선택지는 크게 두 가지가 있습니다.
.NET Framework와 .NET Core 모두 지원합니다. 다만 애플리케이션 코드를 C++/CLI로 컴파일한다는 의미는 기본적으로 x86, x64, arm, arm64용 바이너리를 뽑는게 아니라 MSIL로 코드를 뽑는다는 의미가 됩니다. 그래서 마이그레이션에 난이도가 클 수 있어, 모든 것을 다 옮기기 보다는 UI 위주로 옮기는 것이 좋은 선택이 될 수 있습니다.
이 방법 역시 .NET Framework와 .NET Core를 모두 지원합니다. 단, 첫 번째 (이전 답변에서 말씀 드린) 방법과 차이가 있는 것은, 애플리케이션은 여전히 네이티브 C/C++을 유지한채로 닷넷 런타임을 초기화해서 네이티브 코드에서 닷넷을 제어하는 방식을 사용하는 것입니다. 이렇게 하면, 보통은 변경하거나 커스터마이징할 수 없는 닷넷 런타임 자체의 속성을 제어할 수 있고 더 넓은 자유도가 주어집니다.
닷넷 프레임워크 런타임 호스팅
Hosting the Common Language Runtime | Microsoft Docs
닷넷 코어 및 닷넷 5 이후 런타임 호스팅
Embedding CoreCLR in your C/C++ application | yizhang82’s blog