You're at the ragged edge of upgrade support (9.x is no longer supported, but I believe upgrade from 9.3 is still supported).
The differences between 9.x and 10.x are legion, which means there are nearly too many possible hang points to mention. You should do as many validity checks as possible before engaging a 9.3->10.2 upgrade. You should certainly run a validation upgrade to verify that 10.2 isn't going to object to corrupt metadata. You should also perform an extra cold backup before attempting upgrade, just in case the upgrade "gets caught between floors" (making it not 9.x compatible, but not 10.x compliant, with no upgrade option offered).
The stretch between these releases is great enough that you should consider creating a new database instance and copying the data in from the source instance (with some extra steps involving coordinate reference optimization and spatial defragmentation). Many folks upgrade in-situ, then complain that their now badly fragmented tables are slower, to which my only reply can be "Yup, pretty much."
We currently do not have the resources (licensing and location) to create any new database instances. Can you provide more detail on how to perform validity checks and how to run a validation upgrade?
I won't deny that it's more work to upgrade to a new instance, but to the best of my knowledge, licensing is by server class, not instance count, so there is no legal prohibition from doing the job right.
There's quite a bit of reading available on this topic: