Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table? Given that bcrypt is intentionally 'slow', this might be a problem for applications with large numbers of users (albeit a one-off cost).
I agree that for small sites, changing the auth check and updating all the existing rows (and deleting/overwriting the old hashes) is probably the best solution though.
> Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table?
No, just SHA1 the password and check, and then bcrypt(SHA1) and check, until the encryption process finishes. Or just check the length, or store the hash type along with the hash, a la Django. These problems are trivial, really.
If you assume 6 million users and one second to compute a password hash, that's a couple of months on a single CPU. Takes a while, but no big deal, and it can proceed while your site stays live.
I agree that for small sites, changing the auth check and updating all the existing rows (and deleting/overwriting the old hashes) is probably the best solution though.