My favorite way would be to store password information as a hash chain, so old users can be immediately upgraded to the latest method while new users just use the latest.

For example, Django currently stores its passwords in a single database column as

  <algorithm>$<iterations>$<salt>$<hash>

So suppose we generalize that to a chain of one or more hash algorithms, with each output fed in as the password to the next, resulting in a final hash:

  <algorithm>$<iterations>$<salt>|<algorithm>$<iterations>$<salt>|$<hash>

For example if you had a user who logged in way back in unsalted md5 days and never logged in again, you might end up with a chain like this:

  md5|sha256$<salt>|bcrypt$<iterations>$<salt>|$<hash>

... and then to upgrade to argon you would grab that string, shove the final hash through argon(), and write back:

  md5|sha256$<salt>|bcrypt$<iterations>$<salt>|argon$<iterations>$<salt>|$<hash>

For new users, or if the old user finally came back and logged in with their correct password, you could then take the opportunity to write back a simplified version:

  argon$<iterations>$<salt>|$<hash>

Iterations could be calibrated differently depending on the chain, if the earlier steps take enough time to matter.

As far as I can tell this is the best possible service you can offer to the users whose long-ago passwords you're storing, short of deleting their passwords entirely. Throwing away the earlier version and replacing it with the argon-wrapped version can't hurt them, and will almost certainly help.

(Usual caveats apply about not doing things that add complexity if you don't need it.)