The first thing I would want to know is if the encoding is deterministic. This should be easy to test. Change the password, but make it the same value. If the value in the DB doesn't change, then it is deterministic. Also try this for a few users. Give them all the same password and see if the DB entries are the same.
If so, you don't really even need to reverse the process. Just write down a DB password value to which you know the corresponding password. If the customer forgets the password, change the DB entry to the known value and they can get back in. If it is not deterministic you may still be able to do this.
From there, operating under the assumption that it is crypto, I would try to see how password length affects DB value length. Are all DB value lengths a multiple of some value? If so you might have your block length. There could be some encoding (base64) though, so that could play into it too.
To get an idea as to whether or not it is crypto protecting the DB you could test the entropy of a number of DB values.
If all else fails, reverse engineer the application.