An auditor's job doesn't end at saying what things should be changed, it should include why as well (granted, we don't know the full content of the auditor's report here, maybe they did say why).
If using md5 had any real benefit I'd say leave it, but what are you gaining?
So use SHA-1 or SHA-2 or SHA-3 or if you really hate NIST standards for some reason then CubeHash or Skein or Blake2 or ...
Then change it again? If you use the most recent available NIST standard it should hopefully be a very long time before meaningful (let alone practical) attacks materialize (if ever). If you end up needing to worry about that in a security audit, consider it a badge of success that your software is still in active use after so many years.
Using an insecure hashing algorithm without a clear and direct need is a bad idea. It introduces the potential for future security problems if the function or resultant hash value is ever used in some unforeseen way by someone who doesn't know better or doesn't think to check. Unless the efficiency gains are truly warranted (ex a hash map implementation, high throughput integrity checking, etc) it's just not worth it.
> a security-related technology was used for a non-security purpose
I would suggest treating all integrity checks as security-related by default since they have a tendency to end up being used that way. (Plus crypto libraries are readily available, free, well tested, generally prioritize stability, and are often highly optimized for the intended domain. Why would you want to avoid such code?)
So yeah, I agree, add SHA-1 to the list of algorithms to reflexively avoid for any and all purposes unless you have a _really_ good reason to use it.
[1] https://www.schneier.com/blog/archives/2020/01/new_sha-1_att...
(1) Code is in part a communication medium. This says "We use MD5"
(2) Code changes. If some sees something cryptohashed, they may use it differently in 5 years.