I'm assuming you're here because this code is critical to your business, it works well enough today, and it can't be easily replaced. You need to keep it working as you go, but you desperately need to modernize it. There's a lot you can do to set yourself up for success, and it's not just tools.
First, get it building in the most current environment available. Is it Visual Studio? Port it to VS2013. Is it Eclipse? Get it into 4.4. Is it not even in an IDE? Get it into one - they're a great timesaver. Pick a refactoring tool, too, something that will help automate common refactoring activities like "extract method." You're going to do that a lot.
Next, get it checked into your source control system, and building on your team's build server. This would also be a good time to revisit the packaging of the deliverables. If you don't already have a task and bug management system like Jira, Mylyn, TFS, Bugzilla, or whatever, get one that integrates into your workflow and your IDE. You have a lot of work to do, and you don't want to waste it filling out Excel spreadsheets. You really need your tools to be as unobtrusive as possible.
There is no sense starting with sub-optimal tools, or fighting a crappy build or development environment. Your time is best spent on coding, and is wasted on everything else.
Now that you're almost ready to get working, build a small suite of automated integration tests before moving on to addressing the architecture. They'll be ugly tests, but you need to know the code is still working as you begin making changes. Make sure the build machine can launch your tests and tell you when they fail.
Now you can dig into the code base. Identify the underlying architecture. Is it event based? Does it closely model MVC? MVVM? Once you clearly define the architecture, break the solution into individually compilable libraries that represent the layers (controller, business logic, data accessors, etc.) Move the existing modules to the most appropriate library project. (Some won't fit cleanly, so you'll end up splitting those into parts later.) For now, make sure it builds and the tests run successfully.
Pick one of the layers to work on first, perhaps the UI, perhaps the data access layer. Get it compiling clean, with no warnings, and turn on the compiler switch to enforce "treat warnings as errors." Run a static code analysis tool (Coverity, Klocwork, Fortify, /Analyze, lint, or anything, really) and fix whatever warnings it gives you.
Tolerate no bugs. As you go through the code, when you find a bug, fix it then and there. Your QA staff will no doubt be finding plenty of bugs on their own, but you need to keep the project as clean as you can.
Next, start refactoring the chosen layer into appropriate subdivisions, such as a controller, business layer interface, etc. You'll want to do a bunch of other housekeeping work here: get rid of globals and singletons, push stray business logic down into the business layer, pull stray UI interactions from the business layer up to the UI layer, etc. This would be a good time to introduce some automated unit tests to the logic you extract and move around. Unit tests force you to make the code testable; things like dependencies on databases, services, files, etc., cause problems with tests, so you start treating them with dependency injection. The primary outcome is that by making your code testable, you make it modular and readable. Plus, you get a few more tests under your belt.
Run a complexity metric across the layer, and look for the highest complexity modules. Start chipping them down. Again, look to adding some unit tests to prove that the code you're isolating does what you claim, and that you're making your logic stateless.
Decide on an exception handling strategy, and make your exception handling consistent. Pick the one appropriate to your app and technology: SEH, try/catch, C-style return codes, whatever, just apply it consistently as you go. Similarly, this would be a good time to review any logging your app does.
One of the most important refactoring tools you have is "Rename Method." If you can't say what the method does in a couple of words, it's too complex and not very modular - use Extract method, then name the results appropriately. Once you get good at naming the parts you extract, you'll probably start to see duplications more clearly. This is the time to sensibly combine the methods that are true duplicates, and distinguish those that are not.
Let your build server put those idle cycles to good use rerunning your tests with every build. Make sure your users remain happy with the product.
It is important to not compromise on code quality on anything you do from here on out. You are here because your predecessors let it go to hell; do not follow them down that path.
Good luck!