Here is how we were able to overcome this:
Issues with adop patch cycle
The Problem we ran into was, that ADAPEXSCHREG "forcibly" updates the fnd_oracle_userid to have the password of the APEX Schema/user as INVALID. This may be a good idea in general, however if you have previously adspliced the APEX schema within E-Business Suite (which may be a good idea for various reason), this will break a follow-up adop cycle. When adop validates to connect to the application that has now an "INVALID" password it fails; thus breaking the ADOP cycle.
As shown in this blog post I've been able to solve this by restoring the entry in fnd_oracle_userid from a backup; however you'll probably prefer to not even run into this situation.
De-Register the custom application
Fortunately it is easy to de-register the custom application. This process is described in 2085355.1 and basically all you have to do is the following:
cd $AD_TOP/bin/ perl adDeregisterCustomProd.pl
De-Registering the application
For at least one customer environment I had to run the process twice; once with an APP-CAPPS Application name and once with the all-lower version.
Validate
After de-registering I checked the fnd_oracle_userid (the record should no longer be anabled) and fnd_application table (the record should be vanished:
Record gone from fnd_application
You should then run an "adop -validate" and finally an (empty) patching cycle.
Only then did I run ADAPEXSCHREG.sql which did then not cause any further issues. I hope Oracle will extend the ADAPEXSCHREG script to do some validations in that area.
Summary
With the above procedure it is possible to use a pre-existing APEX parsing schema with the new 12.2 APEX for EBS extension.