Unless the upgrade manager validates that only one soft type or type exists,
it should not care. We never deployed this to production, but never had any
complaints during testing either. It blows up in the 9.1 type manager
because there is code that specifically prohibits soft typing cad docs built
into the type manager applet, but to the underlying code provided the types
are created correct with SQL, it's a non issue. You just have to be
prepared to support it in a non traditional way. There is a column in the
epmdocument table (like others) that is used to associate its soft type, so
it can be easily undone to OOTB temporarily during an upgrade and set back
after.
I did this with numbering, I removed the indexes for number uniqueness.
Allowed the drawing, part, and assembly of same cad format in same
organization to have the same number. Upgrade manager complained the index
was missing, so it make it unique during the upgrade process, I binded the
ida2a2 of the epmdocumentmaster to the end of the number string (with the
help of a coworker whose best skill is SQL) and also created an inverted
query for post upgrade. (Anything to make it unique.) We then temporarily
restored the Oracle index and proceeded with upgrade rehearsal; no issues.
I mention this only because you had spoken of numbering but also to glimpse
into what sort of QA checks the upgrade manager performs to what depth.
