Addressing the issue here would be the better option, where the issue is that magic colours have presumably been used throughout the project, instead of being bound to a single source of truth. For example, colours (HEX) stored inside of a client tag(s) (individual or in datasets).
If this were the case, then this change is simple: make the few changes in the source colours, and then job done. It also means that anything new doesn't have to refer to another component to get the colours right, they're named appropriately at the source and can simply be picked. If you look at my posts in the topic below as well, if you use a dataset tag and a lookup function, you don't even have to pick a source colour - the lookup simply looks up the colour for you (although I don't have a solution for blinking colours using the dataset method at the moment - I haven't really thought much about it since we're now using Perspective). For individual colour tags, I used to use:
case({<Device Status Tag Path>}
,'Stopped', {[Client]System/Styles/Colours/Device/Off}
,'Running', {[Client]System/Styles/Colours/Device/On}
,'Faulted', if({[Client]System/Util/Clock_1s}, {[Client]System/Styles/Colours/Device/Faulted}, {[Client]System/Styles/Colours/Device/Faulted_Flash})
,'Invalid', {[Client]System/Styles/Colours/Device/INVALID}
)
Obviously, Perspective does this far more superiorly to Vision with its Perspective Styles, but you can at least have a basic version of this in Vision.
Have a read of this topic for more ideas: