MFC and C++ Consultancy: Is There Still Demand for Legacy Windows Specialists?

Yes — and not just for maintenance. Win32, COM and MFC still sit underneath production software in engineering, finance and medical sectors. Here is what the role actually looks like in 2026, and why Mapsoft still writes MFC code today.

← Back to Blog

MFC and C++ consultancy — Visual Studio, Win32, and legacy Windows-native development

Yes, MFC and C++ Specialists Are Still in Demand

Every few years someone declares MFC dead. Every few years the demand for engineers who can read it, debug it and extend it goes up rather than down. Microsoft Foundation Classes (MFC) is now over three decades old, and that age is precisely the point: huge volumes of production software written in the late 1990s and 2000s are still in service, still under maintenance contracts, and still being extended. Replacing it wholesale is usually neither commercially viable nor technically necessary, so the work is to keep it running, modernise it where it touches new requirements, and keep the C++ underneath it healthy.

The demand concentrates in sectors that built complex desktop applications when MFC was the obvious choice and where the cost of rewriting is prohibitive. Industrial engineering and CAD/CAM, finance and trading platforms, medical imaging and laboratory instrumentation, defence, and document-processing tools (including Adobe Acrobat plugins) all routinely surface as employers and clients. These are not nostalgia engagements. They are systems that work and that customers have been trained on, validated against, or are contractually bound to.

What Clients Actually Hire MFC/C++ Consultants For

The work falls into a small number of recurring shapes:

  • Maintenance of large legacy codebases. Bug fixes, regressions surfaced by a Windows update, third-party SDK upgrades, build-system rescues when the original developer has retired.
  • 32-bit to 64-bit migration. Still one of the most common engagements: pointer-arithmetic audits, Win32 type widenings, MFC and OCX dependencies that have to be replaced, installer and registration changes.
  • UI modernisation. CDialog-based interfaces look and feel like 2003. Modernising them — whether by reskinning with newer MFC visual styles, embedding WebView2 panels, or carving out specific screens for replacement — without rewriting the whole app.
  • Modern C++ integration. Bringing C++17/20 idioms (smart pointers, ranges, structured bindings, std::filesystem) into a codebase that still uses raw HANDLEs and CString. Done carefully, this is some of the highest-leverage work you can do on an MFC codebase.
  • Diagnostics on production issues. Memory leaks, heap corruption, COM-marshalling failures, threading deadlocks. The kind of problem that requires WinDbg, Process Monitor and an actual understanding of how the Windows loader, the COM apartment model and MFC message routing all interact.
  • Extending the application. Adding new file formats, integrating cloud services, exposing automation interfaces (COM, REST), or building plugins against the existing architecture rather than wholesale replacement.

The Core Skill Profile

The technical bar for this work is genuinely high, because the surface area is wide. Anyone selling themselves as an MFC/C++ consultant should be comfortable across roughly the following:

  • Legacy code mastery. Deep understanding of the Win32 API, COM (apartments, marshalling, IDL, type libraries), and the MFC document/view architecture, message maps, and serialisation. Comfort reading code written by other people, sometimes badly, often with no comments.
  • Modern C++ proficiency. C++14/17/20 fluency — STL containers and algorithms, smart pointers, move semantics, lambdas, constexpr. The ability to introduce these into MFC code without breaking ABI assumptions or upsetting the message-map machinery.
  • Application modernisation. Concrete experience with 32-to-64-bit migration, Unicode conversions (TCHAR cleanup), DPI awareness for high-resolution displays, Windows 10/11 deployment, and migrating away from deprecated controls and OCXes.
  • Diagnostics and debugging. Visual Studio debugger (including remote debugging into production-like environments), WinDbg with the symbol server, Application Verifier, Process Monitor, ETW traces. Knowing how to read a minidump from a customer site without needing the original source tree to reproduce.
  • Soft skills. The ability to explain to a non-technical sponsor why their twenty-year-old application is worth keeping, what the risks are, and what a sensible modernisation roadmap looks like. Most MFC engagements stall on stakeholder buy-in, not on code.

Background and Experience

Most clients expect a computer science or software engineering background and a track record on Windows-native development — typically three years for support-level work, and ten or more for the architecture-level engagements where you are guiding the next decade of a product. Domain knowledge matters too: writing MFC for a medical imaging vendor demands familiarity with DICOM, regulatory constraints and validation lifecycles in a way that pure C++ skill does not cover.

The other thing that distinguishes a working MFC consultant from someone who used to write MFC is currency. Visual Studio 2022, the latest Windows SDK, the current Microsoft C++ compiler — if you are not building production MFC against modern tooling on a regular basis, the gap between what you remember and what the build system actually does today is wider than it looks.

Why Mapsoft Still Writes MFC in 2026

The Adobe Acrobat plugin SDK is a C/C++ interface on Windows, and substantial parts of the existing reference samples and the surrounding tooling were built on MFC. Many of the long-running plugins we maintain — Bookmarker, TOC Builder, Impress, Dogears and others — still have MFC underneath their dialogs and document-handling code. Acrobat itself runs as a Win32 host, the plugin loads in-process, and MFC remains a perfectly serviceable way to put a dialog on screen, manage a property sheet, or wire up a docking pane.

That has shaped our practice. We have not deprecated MFC internally; we have integrated it with modern C++ patterns where it helps and left it alone where it does not. The same engineers who write our newer Acrobat SDK code in modern C++ also maintain MFC dialogs from the mid-2000s. That continuity is unusual, and it is one of the reasons clients with legacy MFC applications come to us — we have not had to relearn what was always normal.

It also means we have practical answers to the questions clients usually arrive with. Is MFC still safe to depend on for the next ten years? Should we port to Qt or WPF? Can we keep the MFC shell and replace just the parts that are hurting? Can we 64-bit-lift an application that has a tangle of OCX dependencies? These are not theoretical to us, because we are still doing them.

Where the Work Is

Most engagements are some mix of remote and on-site, with the on-site time concentrated at the start (architectural discovery, gaining build-system access) and at moments of integration. Geographically, the demand clusters around industrial and financial hubs — the south-east of England, parts of Germany and Switzerland, the US east coast, and pockets of east Asia for industrial automation. But because the work itself is so tool-heavy, a great deal of it is now done remotely, with codebases shared through a VPN and screen-shares for the hands-on debugging sessions.

Fixed-price project work is common in this space and tends to work better than time-and-materials when the scope can be properly bounded — for example, a 64-bit migration of a defined module, or a UI refresh of a specified set of dialogs. Open-ended retained-capacity arrangements suit the ongoing-maintenance pattern, where a small predictable number of hours per month keeps an application alive without the client having to staff for MFC expertise internally.

If You Have an MFC or C++ Codebase That Needs Help

Mapsoft offers MFC and C++ consultancy as a service alongside our custom development and workflow consultancy practices. We will read the codebase before we quote anything, scope what is actually broken (as opposed to what feels broken), and suggest the smallest intervention that gets you to where you need to be. If the right answer is to replace the application, we will say so — but in our experience it rarely is.

If this is the position you are in, the easiest next step is to get in touch. We will sign an NDA if the codebase is sensitive (a template is on the consultancy page), and a short call is usually enough to tell whether the engagement is a good fit on both sides.

Related Articles

The Acrobat Software Developer's Kit

Harnessing the power of C++ and Visual Studio to modify PDFs with the Acrobat SDK. The three layers of the SDK, the toolchain, and what kinds of plugins are commercially worthwhile.

64-bit Plugin Update

The 32-to-64-bit lift for our Acrobat plugin range — what changed, what broke, and the patterns that survive a Win32 widening.

How to Create a Plug-in for Adobe Acrobat

Step-by-step tutorial on adding a custom menu item using the Acrobat SDK, C++ and Visual Studio.

Need an MFC or C++ Engineer Who Still Ships?

Mapsoft maintains and extends Windows-native C++ and MFC codebases as part of our day-to-day work. Contact us to discuss your project.