For a long time hash functions have required a work-factor in order to keep the operation "slow" enough to protect individual passwords in the case of a database leak. Bcrypt and PBKDF2 being notable examples.
I'm also aware of the "Don't Roll Your Own" when it comes to security, but it's easy to imagine a situation that over time the work factor of your password hashing scheme becomes too quick because of hardware increases. One could also imagine a situation where the owners of the database upgrade their own hardware and thus a higher work-factor is suitable compared to what was being used before the hardware upgrade to ensure better safety per-password.
The problem comes with having to "re-hash" a password, because you don't want to store a plaintext or even an encrypted password in a database so the system has no way to access the password again for rehashing to change the work factor. To fix this, simply do this re-hashing when a user logs in. Whenever the user logs in their plaintext password is already available to the system, on a successful hash verification of the password the system can check the previous work-factor associated with the hash of the password (easy to do in bcrypt) and if it is less than the standard work-factor selected by the system operators then the plaintext password is rehashed and stored with the new work-factor and new salt. Sessions don't need to be reset as the same password is being used as before, just a different work-factor and salt.
Apart from the plaintext password being in memory for slightly longer during the verification of the password and an increased time in verifying the password whenever a work-factor increase is issued, I can't find any faults of this model. Are there any security flaws that I have missed?