As an admin/developer, I am curious to know what everyone's thoughts are on going through an initiative of redoing custom field internal IDs. Reason I ask is that I just started a new gig with a company and they've been on NS for some years now. They have had a VERY bad habit of not giving clearer labels to their internal ids (you see 'custbody29' for a free form text field instead of 'custbody_scac_code'). Is there value in it? Too risky? For what it's worth, my actual policy going forward I am going to want to institute is leaving everything alone from the past but begin a naming convention going forward.

The only risk I see is that if there are any scripts that are using the current ids, it will break if you update them

That's the very first thing I do. StrongPoint has a saved search/script that surfaces those.

depends on how customized the account is

Saw this bad boy the other day: ChrisB_UE_SO_sent So we have: 1. UE (we can see that from the script) 2. SO (we can see that in the deployment), 3. The authors name (useless information and available on the system notes). 4. At least we know something was sent somewhere though :) In all seriousness, this is a large risk due to the number of dependencies on those field IDs. I don't know if strong point will accurately find all of those dependencies. I usually create standards and governance as I go rather than try to clean up everything that came before me, unless I'm very sure that a change isn't going to be a breaking change. As a starting point, you could add the help text to the custom fields, at least that will make it clear what they are used for.

Establish a standard. If you touch code, bring it up to the standard. It's a pain at first, but it's how you gain speed.