Then, simply iterate through the keys in this map to populate a new hash that has the preferred field-names in it. (Since both hashes contain references to the data in most cases, there probably won’t be too-much data actually moving around in memory as you do this.)

(Notice the comment that I made in the code-block. $FIELD_MAP is supposed to define every field-name that this program expects to deal with in the data, and I think that your code should die if it ever encounters a field-name that is not. I think that code should never be “trustful,” especially of remote systems. (Data-providers and data-consumers have bugs in their code all the time, just like we all do, so don’t let ’em grind you down...)

This approach will have a number of advantages: it will encapsulate the interface on behalf of the rest of the system or systems, and it will provide a consistent (and well-documented in the code ...) naming convention that remains the same as before. (If you have a number of inconsistent systems on your side, subclassing could be used to good effect.) The package is also suspicious of its host, therefore trustworthy: if it runs to completion, it must be doing the right thing.