I have a geodatabase built in ArcMap from a few years ago that I am trying to use in ArcGIS Pro. The database has roughly 75 domains associated with it that I would like to preserve. My problem is that they are all in the text field type which cannot be modified, and I need about half of them to be integers so that they can be used as Subtypes for feature classes.
Is there an efficient way to create new domains with the old values in the correct field type?
I would probably iterate through each domain and use Domain To Table (Data Management)—ArcGIS Pro | Documentation
to create an in memory table, then use Add Field (setting the field type as desired INT) and then Calculate Field to cast the old values in as INTs e.g. Python - int(oldField).
Then use the reverse (Table to Domain) to put these back into the workspace/FGDB with the new field types.
There may be much better ways (I didn't see Alter Domain being able to alter field types) so this is just my crazy thoughts on it.
I don't think there is a very efficient way to do this, as you would need to remove the domains from all the fields they refer to, add new fields, and create new domains of the correct type referring to the new fields.
Are you extremely sure you need to create subtypes? They are a very specialized thing and are only really appropriate when you have a single feature class than has all the same fields but different domains and defaults (and maybe different topology rules) for different groups. The example I use when teaching is water pipes, where some are trunks, some are mains, some are laterals, they all have the same fields and can be one feature class but each may have a default type and size and maybe different domains as well.
If you have 75 (!) domains i wouldn't do anything in a hurry because it seems to me you have a major geodatabase design challenge on your hands.
This GDB was created by a GIS novice, so it was probably always going to be a bit clunkier than it needed to be.
It's an archaeological inventory that is intended to be used in Collector/Field Maps. So, the idea is that the feature classes (there are about 15 of those), are the general categories (structures, ceramics, lithics, etc.). The subtypes are subcategories (for ceramic: grey ware, red ware, etc.) which with there are specific domain options based on the subcategory chosen.
The subtypes allow us to maximize use of drop down menus that give us consistent values, while minimizing the number of feature classes. Without them our drop down menus would be massive.
This does sound like an appropriate use of subtypes, but a complex data design is not without cost. I do recommend you do data design from scratch and then load data into the new data model, much easier than trying to retrofit a data model in-place.
Another thing to consider if the main use case for the domains is field data collection is Survey123 with XLSForms, this allows a lot of flexibility for a complex data collection task, for example if you choose a certain type of object, you can make fields that are not needed disappear from the form experience so they aren't in the way. The XLSForms programming is not trivial but if you get it working it makes the data collection user experience really easy and simple.