This is the ''age-old'' question when companies allow multiple projects to have different customizations.
Since existing projects have already ''diverged'', there is nothing you can do about it.
Some companies go to extremes by creating custom API code to copy data from one custom field to another across all ''defects'' in a project, for instance, but even then, you have ''used up'' the custom fields already with something else (BG_USER_02 is used differently in various projects).
I consulted for a large telecom customer that had over 300 projects that ''diverged'' and they gave up trying to ''standardize''.
They eventually allowed the projects to complete and the problem went away via ''attrition''.
When they went from an ENTERPRISE to an ''ALM''/''Premier'' level license, they opened up the true ''template'' behavior where ADDITIONAL custom fields can be added and managed through a special project type called a ''template''. These fields have ''TEMPLATE'' in the underlying field name and do not conflict with existing custom fields local to the project. They dabbled with API code to copy values from the local (i.e. BG_USER_02) to the ''TEMPLATE equivalent, but it was extremely tedious and not very fruitful.
All NEW projects will be using the STANDARD set of custom fields and any new fields or customizations go through a change control board