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