IMO the best practice for starting this migration is dependent upon the caller of the procs. Meaning, where you need to abstract, fork, migrate, write test case

IMO the best practice for starting this migration is dependent upon the caller of the procs. Meaning, where you need to abstract, fork, migrate, write test cases at, etc are at that level. There are too many idiosyncrasies between vendor-dependent plsql to do much more than migrate data and calling code (after having written test cases first to confirm functionality equivalence). Often this can include bidirectional data synchronization between independent DBs during the transition. An apt comparison is a temporary bridge built to serve only during the construction phase of large road projects. Don't be tempted to improve things while migrating, one refactor purpose at a time (accuracy/compatibility, and once complete, then improvements).