Time Critical Application Migration from MFC

I rather agree with Solution 2. My answers:

1. Quick Questions & Answer might be not the most suitable place for such a wide problem, but main idea could be: don't assume you migrate; you create the system from scratch, because the technologies are very different. Consider it as a benefit: you can build new system properly, not replicating old mistakes.

2-3. It depends on how good or bad old application was. Other answers give you some ideas.

4. I would not draw the boundary between C++ and .NET between front and back end. In general case, it won't give you any benefits. Rather, you can try to leave C++ pieces which are certainly well written, in particular, with very good efficiency. Say, if you created very fast C++ image processing, your can use it while showing the result of processing in .NET UI. For interoperability, you can use P/Invoke, but it would be much better to use C++/CLI, which is a standardize language (under ECMA 372; please see the links below). You can utilize the possibility of creation of mixed-mode (managed+unmanaged) C++/CLI project with really smooth boundary between managed and unmanaged. Please see:
http://en.wikipedia.org/wiki/C%2B%2B/CLI[^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[^],
http://www.gotw.ca/publications/C++CLIRationale.pdf[^],
http://msdn.microsoft.com/en-us/library/xey702bw.aspx[^].

5. No way. Please see above.

6. What repeatability? It everything is written correctly, without race conditions, only timing can be non-repeatable, not logic. Timing depends on many factors; so it's impossible to give one short answer. Again, you can fill bottlenecks with faster C++ code, but it all depends on how it's all engineered; many managed to create much slower code with C++… Don't forget that, in particular, you can also go away for .NET JIT delays by using NGEN. Please see:
http://en.wikipedia.org/wiki/Just-in-time_compilation[^],
http://msdn.microsoft.com/en-us/magazine/cc163610.aspx[^].

—SA

It's depends on how much your core implementation is coupled with your UI. For instance, if you use a window handle to the window that the graphic should be paint on, in your core code (not a recommended pattern but, I already saw an implementation like this), creating UI with a new platform can require changes in the core implementation too. In addition to that, while the underlying model of rendering the Windows Form is same as MFC in that issue (depends on windows handles), in WPF it's completely different (depends on DirectX). So, in that case, WPF may be removed from the options list.

But, if your UI is completely decoupled form your core, you can keep your core implemented with C++ and, write a WPF UI for it. For more details about wrapping C++ implementation to be used with C# code, you can read my CP article about: Exposing native to managed - C++/CLI vs. P/Invoke.

It is not so much the CPU load that I would fear in a managed environment, but the unknown interference of the garbage collector.

Splitting the app into a managed front end and a C++ non-managed backend gives you nice options for the UI (Windows Forms), but you are introducing some complexity by creating a mixed debugging environment. For that reason, I would stick with a pure C++ application. That decision could be debated, however.

Whether to use MFC11 or creating your own, more modern UI environment is up to you. I would go for the latter.