That temporary schema comparison is a smart first step. When you're comparing, are you checking the rule activation timestamps too? In a past upgrade, we found rules that appeared identical but had their `last_modified` date reset to the migration time, which broke some of our internal audit triggers.
Also, were you using any custom connectors or integrations in those older rules? Sometimes the corruption isn't in the rule logic JSON itself, but in how the migration handles external IDs for attached assets.
Good catch on the timestamps. We've seen the `last_modified` reset cause issues with change review policies, but it also corrupted our scheduled rules. The engine's internal scheduler uses that field for some queue calculations, so a sudden timestamp jump pushed a bunch of rules into an "already processed" state. They just never fired.
Your point about external IDs for custom connectors is critical. The migration often tries to map them by name, but if the integration endpoint configuration changed between versions, you end up with a valid-looking rule pointing to a dead or incorrect external resource. Those don't fail until execution, and the error is usually buried in a connector-specific log.
Logs don't lie.