First, you need a code refactoring tool. That will help you to change the names without bothering about validity of the code as it will be checked by the tool.
This kind of problem where names change happen all the time, and it's a good idea to make sure you concepts in code does match the domain-specific concept. Most of the time you'll not get it on the first try so always assume that names could change.
That's why refactoring tools exists, and that's why it's really important to have one.
Second, if you can't use a refactoring tool, you then have two options :
- Do the refactoring at hand, then as suggested by Marco, you should first evaluate how much you have to do and make sure it is possible with your current resources (aka time aka money).
- Don't change the code. That will work for a short time but later it will make harder to get into the code as you'll have to REMEMBER the indirect names of the changes contexts. Naming concepts in codes is exactly done to not have to remember about them, you read them and you (should) know what it's about. So avoiding any mental weight on code knowledge is really really important, particularly if the codebase is big and/or if you'll get to another project and comme back to this one later - will you remember? So if you decide to not change the code, make sure it's temporary. Relying on experience I would do 1. anyway because most of the time temporary code becomes permanent...
So, change it anyway, your future self will thank you.