Revision control: show the domain experts the benefit of being able to revert, see who changed what, etc. (This is tougher with all-binary files, but if the contents are indeed code, surely there is some sort of G2-to-text converter that can enable diffs.)
Continuous integration and test: get the domain experts involved in creating end-to-end tests (easier, since they must already have inputs and expected outputs somewhere) and small unit tests (harder, because spaghetti code probably involves lots of global variables) that cover nearly all functionality and use cases.
Refactor common code into reusable routines and components. Non-software people with no revision control probably copy-and-paste 100s of lines at a time to make routines. Find them and refactor them, showing that all the tests pass and the code has gotten shorter. This will also help you to learn its architecture. If you're lucky by the time you have to start making the hard architectural decisions, you might be down to 100KLOC.
Politically, if you find resistance from the old timers in this process, hire a consultant to come in and give a talk about good software methodology. Make sure you find a good one whose views you agree with, and get management to buy off on the necessity of the consultant even if the domain experts don't. (They should agree - after all, they hired you, so evidently they realize that they need software engineering expertise.) This is a money-wasting trick, of course, but the reason is that if you - the new hotshot youngster programmer - tell them they need to do something, they may ignore it. But if management pays a consultant $5000 to come in and tell them what they need to do, they'll put more faith in it. Bonus points: get the consultant to advise twice as much change as you really want, then you can be the "good guy" and side with the domain experts, compromising to only change half as much as the consultant suggested.