Most of my experience is rebuilding software that's in really deep. Often the team is reluctant to make changes. What I do is make changes anyway. But I start small. I add unit tests around existing code. I try to cover exceptional cases in those unit tests (bad input, network loss, etc). I can then say, "At least you know how component X works".
From unit tests, I branch out to refactoring code that calls that unit. Often this is changing static method calls into objects with dependency injection. While I'm at this, I unit test the changed components.
Eventually, I get the code up to higher standard. Along the way I can start to produce artifacts that I take to management. Code coverage, # of passing tests, # of failing tests, who broke the build. Team members often want to see these too. Those who still don't want change either leave or come around due to managerial pressure (a valid use of management).
You might be able to do this as well. You might not. It could be that best you can do is carve out a little fiefdom of standards sanity. If you decide to leave after your year's up, fine. You now have experience in the field with a modern tool set. If you improved the conditions, you might re-evaluate.