Hi Toney,

I went through a similar process from Calgary to Fuji recently and realised some 100 or so items needed restoring to OTB.   My work flow was to review the skipped updates and revert if necessary, or capture actual updates to an update set as you have done.   You can't capture the revert to OTB in an update set as that would itself cause the item to be customer modified and thus skipped.

This next bit sounds ridiculous, but the same process needs to be repeated on test and prod, depending on how close your instances are customisation wise.   So I filtered all reverted items from the sys_upgrade_history table on dev, exported the filenames (which are consistent between instances) to a text file and created a query I could run on test & prod which showed the file was not reverted where the filename was one of those I wanted to revert.   Then it was just a manual churn exercise to revert them with a few hundred clicks.   The upgrade process then became allow the platform update to finish, deploy my update sets then work through the report reverting each update I wanted to restore, it ended up just being an exercise in clicking.

Any actual conflicts in your update set still need to be previewed and assessed manually during the upgrade, but in theory you should only get those if items are newer on your test or prod instances which shouldn't be the case.  

In hindsight I could have gone through assets before the upgrade and mark as Replace on Upgrade - but that is quite fragmented as you'd have to jump between different types of record.

Kind regards,

Simon