This is tricky to solve. And with the limited data provided in the question, there are a few steps that I would suggest you take:
- Backup!!! No need to emphasize more as this is production environment. The following steps should be carried out on your local setup and not production.
- Find out what changed in the entities. The change should most probably be in the field settings for one or more fields in the entity types listed in the messages. Check with the developer if you are not sure about the changes. If the changes are not desired, simply export the current configuration using
drush cex and push it. If this is the case, then it will be ideal for all. If not continue to next step.
- Since deleting the fields is not an option as it would delete the data, create a new field with exactly the same label but different machine name. These fields could have desired settings.
- Write a script (update hook, migration, drush command - recommended, etc) which will copy the data from the original fields' to the new field with the correct settings.
- This script could also then delete the field with the older setting which was preventing the config import.
Note: You need to consider the usage of the field at the implementation level and make sure you handle those. Like:
- In any view mode for the entities.
- In any view.
- Any preprocess function.
- If the field template has been overridden.
The data is very crucial here. So TEST, TEST, and TEST! Everything would be easy if there are a limited amount of entities with values in the conflicting fields and that the data could be handled manually by deleting the fields.