Hash function collisions are not relevant to password hashing. All the password hashing works on preimage resistance, not collisions. You can forget everything about collisions when talking about password hashing.
Salt "collisions" may matter but are better called "salt reuse". You avoid salt reuse by using big enough random salts (16 bytes are enough; GUID are good salts).
You cannot change the salt without having access to the password. If you could do it, then the attacker could do it too, and nullify the benefits of the salts. This would be a serious weakness of the hashing function.
There is no point in changing the salt. The salt unique added value is how it is different from other salt values. There is no gain in replacing a salt value with another value; there can be a net loss if the new value happens to be equal to another salt value, leading to salt reuse.
Namely, when you use random salts, you are ensuring absence of salt reuse heuristically: if you ever generate s salts, in a space of size n (e.g. n = 2128 for random 16-byte salts), then risk of a salt reuse remains low as long as s2 is small with regards to n. Basically, with 16-byte salts, chosen randomly from a good PRNG, you have room for about 264 salt generation instances. If you change salts regularly, more often than strictly required, then you are increasing s, i.e. diminishing your breathing room. Fortunately, 264 is a huge number, so assuming that you do everything else properly, then replacing salts every week (when the user logs in, because you cannot do that without the password itself) will not imply a significant extra risk. It will be useless, but harmless.
If, from multiple hash values with various salts and the same password, the attacker can work out the password itself or reduce its key space (with better success than the simple risk of salt reuse explained above), then this is a cryptographic weakness of the password hashing function. No such weakness is known for usual password hashing functions (bcrypt, PBKDF2...).