In my specific situation the old O_H had PSU 18.104.22.168.3 + some one-off + Patch:21355879.
This Patch is not needed anymore in my new O_H (22.214.171.124.4 + some other one-off) - I checked on My Oracle Support - Patches & Updates:
So no need (and no simple way) to add this patch to the new O_H at all.
But when running datapatch within the new O_H, it throws this error and refuses to continue:
Error: prereq checks failed! patch 21355879: rollback script /appl/oracle/product/rdbms_121024Jc/sqlpatch/21355879/19095143/21355879_rollback.sql does not exist Prereq check failed, exiting without installing any patches.
It's obvious the patch 21355879 is not installed within the new O_H. But somehow ( I did not check the exact internal function) datapatch checks the view DBA_REGISTRY_SQLPATCH and finds PATCH_ID:21355879. With a statement similar to
SELECT XMLSerialize(CONTENT dbms_sqlpatch.opatch_registry_state INDENT) from dual;it finds the patchuid 19095143. The base table seems to be OPATCH_XINV_TAB. (the other patches within 21355879 are not in this XML and doesn't require a rollback script).
So the database repository says a rollback script should be present, but it's not installed in the new O_H as Oracle calls it not required anymore.
The clean solution would be to patch every new O_H in the exact sequence of all it predecessors - this can be time consuming and also challenging when different branches with conflicting one-offs needs to be merged - even all these conflicting one-offs are merged in a later PSU and not needed anymore.
We decided to do the easier way and just copy all patch directories from old onto new O_H.