One thing about automated testing is that it requires you to write code to be testable. This is not a bad thing in and of itself (in fact it's good because it discourages a lot of practices that as a rule should be avoided), but if you're trying to apply unit testing to existing code then the chances are it's not been written in a testable way.
Things like singletons, static methods, registries, service locators and so on introduce dependencies that are very difficult to mock out. Violations of the Law of Demeter mean that too many parts of your code base know too much about how other parts of your codebase function, introducing further hidden dependencies that can be difficult to break. All these things make it difficult to isolate a module from the rest of the code base, and if you can't test your modules in isolation then unit tests lose a lot of their value. If a test fails is it because of a fault in the unit under test, or because of a fault in one of its dependencies, or perhaps it's because the data that's being pulled in through a dependant data source isn't what the test writer expected? If you can't replace dependencies with mocks then any of those are a possibility.
Most codebases I've seen that weren't built with unit testing in mind tend to be inherently untestable, as coders tend to focus on making the code work as they expect it should rather than doing the work necessary to keep coupling loose and dependencies explicit. Code that was written with unit testing in mind tends to look very different.
A lot of people take a naive approach to unit testing when they start doing it for the first time, they think they can just write a load of tests for an existing codebase and all will be good, but it never works out that way because of the above mentioned issues. They start discovering they have to inordinate amounts of setup in unit tests to get them to run at all, and the results are often questionable because the lack of isolation in the code means you can't track down what caused a test failure. They also tend to start off trying to write "clever" tests that demonstrate some highly abstract aspect of how the system should work. This tends to fail because a "clever" unit test is a potential source of bugs in itself. Did the test fail because of a bug in the tested module, or because of a bug in the test? A test should be so excruciating simple that there's obviously no possibility that a bug could be hiding in it. In fact the best tests are rarely more than 2 lines long, the first line instructing the unit under test to do something, the second asserting that what it did was what was expected.
If your team is serious about adopting unit testing then it would be unwise to start with an existing project. Your team's existing projects are probably untestable without major refactoring. You're better off using a new project as the basis of learning about unit testing, as you have a clean slate to work with. You can design the new code base to favour dependency injection over singletons, registries and other such hidden dependencies, you can write it to depend on interfaces instead of implementations and so on. You can also (and should) write the tests along side the code being tested, as writing the tests afterwards results in unit tests that make sure the tested module does what you think it might be meant to do rather than ones that test that it does what the specs say it should do.
Once you've gained some confidence with unit testing, your team will probably begin to realise the flaws in their existing code that are going to be obstacles to unit tests. This is when you can start working to refactor existing code to make it more testable. Don't be ambitious and attempt to do this all at once, or attempt to replace a system that works with an entirely new one, simply start by finding the bits of the codebase that can easily be tested (the ones that don't have any dependencies or where the dependencies are obvious) and write tests for those. I know I said writing a test alongside code is preferable to writing tests after, but even a test written later still has value as a starting point. Write the tests as if you know nothing about how the class works other than what its specifications say it should do. When you run the tests and get failures, then either the specs or the implementation is wrong. Double check both to determine which is wrong and update either the test or the code accordingly.
Once you've picked off the low-hanging fruit, your real work begins. You need to start finding the hidden dependencies in your codebase and correcting them, one at a time. Don't get over-ambitious at this point, just stick to doing one module at a time, or even just one single issue in one module, until the obstacles to testing are fixed and you can move on to the next bit.
TL:DR: Most people think testing is easy and you can retrofit tests into existing code easily. Both of these assumptions are wrong. If you embark on a project to get unit testing into your projects with both these facts in mind you're more likely to succeed.
