"Pre-G MID Upgrade ECC Blocker" and "Disable Pre-G Blocker BR" business rules are listed as skipped customisations, when they are not, and should not be revertedDescription2 business rules were introduced from Geneva Patch 6 as the fix for PRB664515, which was to prevent an issue caused by version mismatches between Geneva instance and MID Server s that had not upgraded to Geneva yet. "Pre-G MID Upgrade ECC Blocker" on ecc_queue /sys_script.do?sys_id=2450c0003702120069da03488e41f1d5"Disable Pre-G Blocker BR" on ecc_agent /sys_script.do?sys_id=210c00803702120069da03488e41f1e4 The purpose of the second business rule was to run on every MID Server record update, check if all MID Servers were upgraded, and then set bot business rules as active=false. There is also a run-once scheduled job "Disable Pre-G MID Upgrade ECC Blocker business rule" added to sys_trigger, that will run as system and deactivate these business rules. This is why the update appears to be as the 'system' user. However the way it does this looks like a customer update or customisation. This is tracked by the sys_update_xml table, in Default update set, and so would be reported as a Skipped upgrade in the Upgrade History from then on.Steps to Reproduce The MID Server plugin and the related tables and code is active on all instances, even if no MID Servers are installed. Upgrade a pre-Vancouver instance to a pre-Vancouver versionCheck the Upgrade History for the upgradeSee the skipped upgrade records for non-customised "sys_script_210c00803702120069da03488e41f1e4" and "sys_script_2450c0003702120069da03488e41f1d5"WorkaroundThis problem is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available. The workaround is to deliberately leave these inactive, and leave this on the customised version. Don't revert the skipped upgrade to out-of-box, because the pre-Vancouver out-of-box versions are active, and we don't want these active. When the fix to this problem is released, the 2 business rules will be replaced by inactive out of box versions, and a fix script will update the sys_update_xml records as replace on update=true. That means on the next upgrade after that updrade, these 2 records will be automatically reverted to the new inactive out-of-box versions, and will no longer show up as skipped upgrades.Related Problem: PRB1625731