Not a direct answer to your question above, but certainly related:
I would recommend generating DDRs of the before and after versions of the files, and perhaps even a DDR or two as you work through your list.
That way, if you wind up with something that appears broken at the end of your process, you have the wherewithal to distinguish whether the breakage was pre-existing, or whether it was the result of the code migration.
Thanks @steve_ssh — I’m using Base Elements to review the DDRs and clean up cruft and broken links. I’ll make sure to run a DDR before I consolidate each feature. My early consolidations should be relatively simple but I’m interested in perfecting the process in preparation for consolidating more complicated functions.
@steverichter Here is a list I've last edited around 2014, you now get to use the clipboard for some more items (like value lists and custom menus):
External file refs (if anything is to remain external) – Copy and Paste
Custom Functions – Copy and Paste or Import
Tables – Copy and Paste or Import
Graph – Manual Fix. Make sure relationships and names are setup correctly
Adjust Fields – Any fields that needed relationships will be need to be adjusted. One way to do this is to delete all the fields and re-copy and paste the fields from the old file to the new. That will break relationships, but those might be easier to fix than all of the broken calcs.
Value Lists – Copy and Paste
Adjust Fields using Value Lists as validation – Manual
Layouts – Manual make the layouts with the correct names. Skip content for now. That comes later
Scripts – Copy and Paste or Import
Themes – Import ( Technically these can go any time before step 9)
Layout Contents – Copy and Paste content, manually set sizes and parts.
Layout Based Script Triggers – Manual
Layout TAB order – Manual
Layout custom margins / columns when printing – Manual
Security ie Accounts and Privilege Sets – Manual
Custom Menus – Copy and Paste
File Options – Default Passwords and Window Based Script Triggers
There are some elements that can bite you either way, so for each specific project, you may want to alter the sequence a bit or do multiple pass. There are things that are difficult to avoid altogether. For instance, fields are required to establish relationships, valid predicates or not, many field options can use relationships (calc, auto-enter, lookup, validation, just about anywhere you can fit a calculated expression), Value-Lists require fields, but fields can also require value lists as a validation, etc. So there are a bunch of "catch 22" scenarios and you will need to look at your specific scenario to figure what is best for you.
Also, watch for possible name conflicts:
In some cases you may want to skip creation altogether (if you have a Yes/No value list in both files, making a replica may not make much sense, objects should simply get mapped to the one value list you already have in your destination file).
Some other times you may have objects that, even if they had the same name, were not conflicting because they were in different files (TOs, layouts, scripts). It could be good to rename using a prefix or suffix with the source file name before moving things around. In some cases, you may even opt to apply that renaming protocol to every object even if they are not conflicting.
Keep in mind that naming conflicts are to be handled for ALL the files involved in the consolidation, not just pairs of files. So if you are consolidating files A, B and C into file A, you want to avoid naming conflicts not only between A+B and A+C, but also with B+C given how B+C will both get consolidated into file A.
@steverichter I know we are on a holiday and people may add to this discussion. That said, if you feel like my post answers your question, I would appreciate if you would mark is as an answer, unless it was not meant to be in the ER, in which case you can simply move it to a different channel. Happy Easter everyone!