Unsalted was not "state of the art" in the 1970s. The database would be far more secure if it had used a weaker hash with salt.
To migrate, Unix-like systems generally support database migration through a modular format (see "man pam_unix" and /etc/pam.d/passwd). The next time the password is changed, the field that looks like $1$<salt>$<md5hashedpasswd> will be converted to $6$<salt>$<sha512hashedpasswd>. I guess you could change it at the next login if you allowed modification to the password table during login. If you were eager, you could just salt and rehash the hashes current hashes. To check that password, you would do the old unsalted md5, then apply the salt and sha512 (or whatever) before checking in the database.
You are right, I just meant to say that the 'awareness' has increased a lot since Last.fm first stepped on the scene. Unless you were already security-savvy and had a hacker (as in the original sense of the word) background, I guess no one really cared back then.
On a sidenote, I just changed passwords for what was probably my second last.fm account and I haven't logged in or 'scrobbled' since 2007. Different times for sure.
To migrate, Unix-like systems generally support database migration through a modular format (see "man pam_unix" and /etc/pam.d/passwd). The next time the password is changed, the field that looks like $1$<salt>$<md5hashedpasswd> will be converted to $6$<salt>$<sha512hashedpasswd>. I guess you could change it at the next login if you allowed modification to the password table during login. If you were eager, you could just salt and rehash the hashes current hashes. To check that password, you would do the old unsalted md5, then apply the salt and sha512 (or whatever) before checking in the database.