I had to do exactly this same migration some months ago on a production database.
We did that in two steps.
- we added an extra password column that would contain the PKDBF2 hash in Crypt format
- then we modified the login logic so that when a user logged in (and we received their plaintext password), if the PKDBF2 field was not NULL, the routine would verify against that. Otherwise, it would check against the old hash column, and - if the plaintext hash matched - insert the information into the PKDBF2 field.
Our users did not notice anything. After maybe a week we also sent a mailing to customers that had not an updated PKDBF2 hash requesting they log in, and update their information while they were at it.
What was noticed was that we also added updated password strength checks (if your password was not strong enough, or its hash had leaked and was available on online databases, a warning would be given and a password change was strongly suggested. If the password was not policy compliant, the change was not an option). Due to a mistake, the checks were added later, so the most assiduous users were able to slip by a potentially unsecure password. Nonetheless, they got hit with the update at the next mandatory password change six months later... the last ones are being processed now, I think.
After, if I recall correctly, six or seven weeks, at the end of July, about 70% of our customers were updated. At that point the logic was changed again and the old hash was disabled, the column dropped. People trying to log received a message that their password was not correct, or had been obsoleted, and they needed to apply for the "Recover password" button.
Then about 10% of customers, more or less, turned out to be "dead" -- they are currently scheduled for removal in accordance with privacy regulations. Those with no business recorded were deleted immediately.