This is more of a comment than an answer since I don't know whether this has been done, but I really doubt mission critical software has switched to a different programming language after the mission started (lift-off).
A change in programming language is a large risk. Every language has its own benefits, disadvantages and quirks that need to be managed.
For example, the C programming languages allows for several constructs that make it easy for the developer to shoot into their foot (e.g. overwrite/corrupt memory) so NASA has a guide on how to use C in its projects and so does ESA (alternative link to the actual ESA C/C++ coding standard since the one from ESAs site didn't load). Depending on the project, even stricter rules may be applied (e.g. no use of dynamic memory allocation).
These rules are often enforced by static analyzers and other tools, so the language is actually part of an ecosystem. Last but not least there should be unit and integration tests. If you change the language you need to change a whole ecosystem and not just the source files of your program.
(There's also actual project management, of course, but I guess this stays roughly the same if you "just" switch a language.)
The development of correct software can be a very tedious and time-consuming task. If you spent months or years developing a mission critical project and then decide to switch the language you need to essentially start from scratch (even if you can port/reuse parts of the original implementation). When you switch a programming language you usually want to do so because the new language allows you to employ coding patterns that solve a problem (e.g. make it easier to implement certain parts or make it safer to do so). But this in turn means that you probably want to at least partly change the design of the original project to make use of these features which introduces even more risks.
Since correctness (or maybe "being able to accurately predict the behaviour") is so important and it's better to work with known issues than introduce new, unknown ones, even changing the compiler (or just the version of a compiler used) is a change that needs to be carefully evaluated. Compilers do have bugs or change the way code is behaving: to use C as an example again, it has so-called undefined behaviour for certain constructs like the famous
i = i++ + i++; where the outcome of the expression is explicitly not defined by the standard and every compiler is allowed to do what it wants (the famous joke being it's allowed to make daemons fly out of your nose in this case). If you change the version of the compiler such code may alter its previous behaviour.
The bottomline is: the change in programming language is a very costly (time and money) task that introduces a lot of risks. The benefit of such a switch must therefor outweigh the costs and risks involved. I can imaging this being the case for software used on the ground (stupid example: switch from an old X11 UNIX software written in C to Java) but I have a hard time imagining this happening for software used in flight hardware.