You can sort of upgrade hashes in place at the cost of extra book keeping.
Take the old hash, and use it as the input to a new stronger hash. Mark some column to indicate you've done this. Then next time the user logs in, you calculate the old hash and then the new hash from that. Once you validate the password use it to calculate a new new hash, put that in the field and clear the update column.
You don't even really need the book keeping - you can update the hash in place as you say, then just try both eg bcrypt . password and bcrypt . md5 . password. It would be even simpler to style all future passwords as bcrypt . md5 . password but I'm not sure of the security implications of that as a permanent measure and so wouldn't do it personally.
Security wise bcrypt(md5(password)) is at least as strong as bcrypt(password). However broken md5 is it is certainly no easier to find a preimage than where you already have the preimage. (Edit: now that I think about it, it could be worse if there is a side channel in your md5 implementation.)
If you do it that way you'll pay a performance cost on every password check forever. I suppose that trade-off might worth it in some cases.
So much of password hashing is a deliberate performance cost anyways, it almost hardly matters if your password passed through md5 and sha{1,2}. bcrypt will eclipse them all in relative cost, as it should be.
This is exactly what facebook do. They've done it several times over, such that a plaintext password goes through about 8 steps before making it into a database.
Take the old hash, and use it as the input to a new stronger hash. Mark some column to indicate you've done this. Then next time the user logs in, you calculate the old hash and then the new hash from that. Once you validate the password use it to calculate a new new hash, put that in the field and clear the update column.