Unfortunately I don't know of a good way to accomplish this. I would suggest viewing and possibly voting on the following Idea:
https://infrastructurecommunity.schneider-electric.com/ideas/1165 Creating of ArcFM tracing geoprocessing tools.
It currently has 27 votes.
We are on ArcFM 10.2. I ran into the same thing a while back so I ended up trying to manage this with Python. In the end, this is still a proof-of-concept which I have not had the need to re-visit, though that could change. In other words, I wrote some software to do what I wanted (my problem was the same as your problem) but I never went back to use the code or idea in a production setting. Without going back and looking at the code, I seem to remember the following:
- New/changed domains, and other changes, were captured in internal (to Python) data structures. I might move these to external text files but in any case, the program would use/read these to "know what to change".
- The current "state" (things that I wanted to change) was also captured before I changed it but I do not remember where I saved this information. Because this state was saved, I could revert to it programmatically, which decreased the risk of making changes.
- The programming was fairly low-level but not ridiculous.
- My extensions were fairly simple but as you pointed out, quite tedious to apply manually, and error-prone. I think that my program could be modified to accommodate more extensive changes; I do not remember any technical issue to prevent this. It seemed to be more a question of how much I wanted to invest in developing the program.
- I am not sure to what extent the program could be generalized but it seemed to be a viable path for at least my limited set of extensions.
BOTTOM LINE: If you are a strong programmer, and have the time, then writing a fair bit of Python to do the work could be a viable option for you.
FOR SCHNEIDER ELECTRIC: For those customers that need to implement extensions, more product support in this area would be very helpful, particularly with scripting/programmatic support. Using the GUI to apply extensive changes is not optimal, and the XML approach seems appropriate for more wholesale changes and less so for targeting to specific areas. More guidance in the documentation on different "extension scenarios" (type and number) and how best to pursue them would also be welcomed by customers.
Yes, looks like there is nothing out there out of the box really to do mass configuration in ArcFM. I found this on the web and will give this a go. Also, our third party developer reckons that it should be fairly possible to put some code together that would do the job. Not really user friendly to be honest, considering that e.g. adding a new subtype to a feature class recently took between 600-700 manual mouse clicks..