1. Add two new columns, a salt column, and a new hash column, initially null.
 2. When an authentication request comes in, check the salt field.
 4. If the field has a value then there is a new-style hash that has pepper and salt added. Handle accordingly.
 5. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the plaintext password from the original request; generate and store a salt and you now have everything needed to compute and store a new-style hash. The legacy system won't know to do any of this, so only the new system can do it. (It would have been better if neither system had to deal with it but could delegate the job to the database itself. The new system can, the old system can't.)

Eventually either everyone has logged in at least once and had their hashes transparently updated (there are no NULL salts left in the table), or the only ones left are those who never log in at all.

Putting the unsalted and salted hashes right next to each other in the table just illustrates the fact that for as long as the legacy system continues to be used, the use of best practices in the new system will continue to be irrelevant from the standpoint of security.