Many programmers like to use object-oriented design in their new programs. That's usually a good idea because it helps to compartmentalize the code: instead of having a bunch of IF POLICY_TYPE = '5' THEN statements scattered through hundreds of programs just waiting for a new code to be introduced, you can define a Policy object and "ask it questions."

But how do you reconcile these ideas with that messy, existing database?

Generally, you visualize the database as being a repository of information that objects know how to use to create themselves. Those same objects know how to store themselves back into the database. Other, "factory" objects know how to search for records and instantiate objects from them. And so on.

The "holy grail" you're looking for is that the objects you design conceal many things. They conceal how the data is stored. They conceal how to get to it. They also conceal what the various fields in the SQL database mean, allowing you instead to "ask the questions you need to ask and get the results you need to get."

There are plenty of OO designs already out there, created by very smart people and available on the Internet for the price of a few hours' searching. Try not to reinvent the wheel.

Realize that you can never "re-write the existing systems" or change their formats to suit your fancy... the existing systems and the new stuff that will be based on your object-designs will be maintained together. Your initial object-designs also will one day be changed, by someone other than you. All of this is simply a fact of the industry.