"The program itself is a physical model of a complex chemical processing plant"

Assuming your software's main goal is to simulate (perhaps optimize, run parameter estimations upon) a complex chemical plant, or parts of one... then I'd like to throw out a rather different suggestion:

You might do well to consider using high-level mathematical modelling language to extract the essence, the core mathematical models, out of hand-coded software.

What a modelling language does is to decouple the description of the problem from the algorithms used to solve the problem. These algorithms are generally applicable to most simulations/optimisations of a given class (e.g. chemical processes) in which case they really shouldn't be re-invented and maintained in-house.

Three commercial packages used widely in your industry are: gPROMS, Aspen Custom Modeller, and (if your models don't include phenomena distributed along spacial domains) there are Modelica-based software packages, such as Dymola.

All of these packages support "extensions" in one way or another, so that if you have parts of your models that require custom programming, they can be encapsulated into an object (e.g. a .DLL) that can be referenced by the equations in the model. Meanwhile, the bulk of your model remains succinct, described in a form easily readable by the scientists directly. This is a much better way to capture your company's knowledge and IP.

Most of these programs should also allow you to 'start small' and port small parts (sub-models) of your monolithic code into their format, by being called externally. This may be a good way to maintain a working system and validate it one piece at a time.

Full disclaimer: I worked as a software engineer at the company behind gPROMS for 8 years. In that time I saw (and occasionally incorporated) examples of custom software (e.g. coming from academia) which had started small and tidy, implementing some clever solution or algorithm, but then exploded over the years with extensions and modifications - without the helpful guidance of a software engineer to keep it clean. (I'm a big fan of multi-disciplinary teams.)

So I can say with some experience that certain key choices made poorly early on in a software's development (like a language or key library) tend to stick around and cause pain for a long long time... They've already 'shaped' the software around them. It sounds to me like you could be facing many many years of pure code cleaning here. (I'm hesitant to use numbers but I'm thinking 10+ person years, maybe much more if you can't get the code ported from G2 to something that supports good automated refactoring tools like Eclipse/Java quick-smart.)

While my default status is to "refactor and keeping a working system", I also think once a problem gets "too big", then a more radical change/re-write becomes faster overall. (And possibly brings additional benefits, like jumping to a more modern technology.) I say that with some experience porting to a new software platform, but from what I gather it's even more dramatic with a port to a mathematical modelling package.

To give some perspective, you might be quite amazed at the size reduction. E.g. the 200,000 LoC could actually be represented in something like 3,000 lines of equations (OK I'm guessing here, but I could try and get you an actual testimonial from friends in the business); plus a few relatively small function modules written in something like C (for example, physical-property calculations - although again off the shelf packages may exist depending on your chemical process). This is because you literally just throw away the algorithmic solution code and let a general-purpose 'stack' of mathematical solvers do the hard work. Once you have simulations running, you can do much more with them, like optimising the process - without changing a line of code.

Finally I would say: if the only reliable documentation of the various mathematical models (and algorithms) is the code itself, you will want the help of the scientists and original authors to help extract those models out, ASAP, not years down the track when some of them may have moved on. They should find that a mathematical modelling language a very natural way to capture those models - they may even (shock horror) enjoy (re)writing it.

Finally, since my answer might be a bit off the mark, I'd just like to add one more book to the list of good books already referenced here: Clean Code by Robert Martin. Full of simple (and justified) tips that are easy to learn and apply, but which could make a world of difference to people developing new code at your company.