Clearly the current table needs to remain so the old application can work.

Maybe add a new table with salted+peppered hashes for the new application to use, then:

• Make the old table inaccessible to the new application!
• Update both tables when updating a user's password
• Require all users of the new system to update/reset their password
• The new table can store a copy of the old hash initially, then update it to be properly hashed when the user updates their password.

This assumes that the password control system is separate from either of the content systems.

This means that any vulnerability in the new system can't access the old hashes (once migrated).

Clearly the current table needs to remain so the old application can work.

Maybe add a new table with salted+peppered hashes for the new application to use, then:

• Make the old table inaccessible to the new application!
• Update both tables when updating a user's password
• Require all users of the new system to update/reset their password
• The new table can store a copy of the old hash initially, then update it to be properly hashed when the user updates their password.

This assumes that the password control system is separate from either of the content systems.

This means that any vulnerability in the new system can't access the old hashes (once migrated). The database could have a vulnerability that allows the new system's database credentials have access to a table it shouldn't, but that's much less likely than your new application having a vulnerability.