It can be hard to work unit tests into legacy code. The first step might not have to do anything with tests at all, but with refactoring/rearchitecting your code to allow for proper unit tests. Without proper abstractions and dependency injection, you'll find it hard to mock out your data access layer.

If you have a hard time convincing colleagues to go along with this, then you'll just have to go ahead and start writing tests over top of a real database (or whatever your data layer is.) They should see pretty quickly how tedious it is to have to maintain a test db, and the benefits of being able to mock it out.

In my opinion, one of the big concerns is isolating the business logic into its own layer that is as loosely coupled to the data access and view layers as possible. Data access and rendering errors are relatively easy to spot in QA/UAT. The errors most likely to make it through black-box testing are related to business logic, which can be dizzying in any app that's been around long enough. It's important to distill the business logic into a single layer where each business rule can be tested individually without the possibility of interference from the view or data layers.