Copy is the only built in function that will do this that I have found, but you are restricted to transferring all Spatial and Attribute settings the same into the target database. Feature datasets may have to be copied in their entirety in some cases.
All other methods, such as using Export and Load to create a new schema or Spatial Reference, always rebuild the OID values. The internal tables that perserve the OIDs for the copy method are not exposed by ESRI to end users through any methods I know of and they are not inclined to let users access these internal tables directly for fear of all the bugs that we would create (and that ESRI willl not support us in resolving).
For all methods other than copy, the old OID values must be preserved into another LONG field on the output to the new gdb, so far as I know. That long field can be used to join the target data back to the original. A number of methods can be used to do that if you cannot modify the original schema to add the field and calculate the OID values to it. This method can be used for rebuilding Feature-Linked Annotation to connect to a new Linked Feature-Class converted to a new Spatial Reference and Schema (I just did it 3 times in the past 3 weeks and finally got a method that worked in about 2 hours for a large SDE dataset with 5 Feature-Linked Annotations that had to be copied twice and reregistered with new permissions.)
Even if you use copy to transfer the old OID values to the new gdb, if you make additions and deletions of records to both the oriiginal and copy independently they will not stay in synch. If synchronizable editing in both the original and copied data is part of your operation, look at using global IDs and Replication through the Distributed Database toolset.
If you really really have to preserve the original OIDs but still transform the feature class Spatial Reference and/or Schema rather than creating a true copy, then about the only way I can think of to do that would involve running an insert cursor to transfer the features from a TableSort object that is sorted on the original ObjectID field. A counter would have to keep track of the record number being inserted and every time an ObjectID skipped one of the counter numbers a bogus feature would have to be inserted with a known bogus attribute value instead of a real feature. Then when all real features are inserted, select the bogus features using the bogus attribute value and run a delete cursor to remove those features. At the end in theory you should have a new feature class loaded with features that have the same OID values as the original feature class, but loaded to a new schema or spatial reference.