If for some reason length was an issue, a base64 encoded 256 bit string, like a SHA-256 digest, is 43 characters. That too can be truncated to 40 characters, which has 238 bits of security. SHA-256 is not only a better hashing algorithm than SHA-1 but it could also result in higher effective security even when truncated.
There's a point where truncating starts to make it weaker, but when you first start chopping off bytes the benefits outweigh the drawbacks.
Generally though length ext attacks have a solution - HMAC, which is much more secure than truncate.
The more you truncate, the more vulnerable you are to birthday attacks (practically speaking you would have to truncate quite a lot)
Also i think the length of the input matters when comparing sha256 vs sha512.
160 bit output, without a cryptographic weakness, is good for about 30 trillion commits per second continuously for 1000 years.
For SHA the cryptographic strength isn't primarily from the length of the hash, but from the internal number of rounds is (e.g. 160-bit SHA-1 with fewer rounds has been badly broken way earlier, and 160-bit SHA-1 with more rounds would be safer).
Cryptographic hashes are designed to be safe to truncate and still have all the safety the truncated length can provide. It's basically a requirement for them being cryptographically strong. Even in the SHA-2 family, the SHA-224 and SHA-384 are just truncated versions of larger hashes.
SHA-1 is quite broken at this point. SHA-256 is not. There aren't any practical non-generic attacks on full sha-256 and thus there wouldn't be any on the truncated version. The Wikipedia article goes into the different attacks on the two algorithms.
That said, if your concern is length extension attacks - strongly reccomend using sha-512/256 instead of trying to do your own custom thing.
It seems like that could ease much of the migration problems if it's not a problem?