There's a lot of good advice here, but I'll add one thing. Learn the codebase really really well. Figure out where the seriously bad problems are. Figure out wh

There's a lot of good advice here, but I'll add one thing. Learn the codebase really really well. Figure out where the seriously bad problems are. Figure out why the codebase is this bad, ideally from the original developers (not in an accusatory fashion, try to frame it as learning from them). Figure out the context of the bad code, otherwise you might end up repeating it. Write up notes and sketches and plans of the bad code. Then, isolate a section that is practically reeking. Maybe it's even so bad that it's leaked into the user experience. It has to be a super small part of the codebase though. Plan out the refactor, making sure to make it backwards compatible (that means no regressions, no changes to internal interfaces, etc.). Start the refactor, then when you reach about the 70% mark (which will be more like the 30% mark considering regressions and stuff), try to pitch the refactor. But don't pitch it as a refactor. Figure out any problem that the user or manager is having, whether it's slowness, crashing, etc. and then slide in your refactor as the solution. Like hiding spinach in brownies. If there aren't any problems, well, then maybe the codebase isn't that bad. And remember, 50% good code and 100% done is better than 100% good code and 50% finished when it comes to refactors.