First up, the fact that you are here, asking this question, is already a large step in the right direction. Few things kill morale more than workers feeling that management does not care about their problems. The fact that you have a mindset geared towards improvement is very important.
Now, I agreed with everything Ewan said, up until the suggestion to rewrite everything.
What you need, with a problem of excessive complexity, is a solution of sufficient power and structure. This includes both the project management side of things and programming.
For the Project Management side of things, this involves several things: Requirements gathering and refinement. Not wasting too much time in unending meetings. Documenting all work done (ideally in a way linked to the source code) so the Team can look back and discover why a piece if code does what it does. Breaking work down sufficiently so that, rather than being overwhelmed by a gigantic piece of work, any given developer has only a single, do-able task on his/her plate (no multi-tasking). Etc.
For the programming side of things, you'll need a system that allows the code to be maintained as easily as possible. I'd suggest looking into Domain-driven design. Take note, however, that any architectural changes need not happen all at once via a wholesale rewrite. If your team implements a policy such that, whenever a developer touches the code, s/he leaves it cleaner and more structures than s/he found it, then you'll be fine.
You don't need to dump all of these changes all at once, either; you can ease them in bit by bit. Provided you get buy-in from the team (implementing any change without buy-in will always reduce morale, which would be counter-productive), then over time, as your system for handling work becomes more robust, the work itself will become simpler, and morale will improve accordingly.
