Your CPU/SOQL Limit problems aren't a volume problem. They're a save-cycle problem

Most "messy org" automation problems come down to one mistake: people add automation to an Object without thinking about the save cycle.

Every time a record saves, Salesforce runs a fixed order of execution. Simplified, the sequence is: before-save flow → before triggers → validation + duplicate rules → record saves → after triggers → legacy workflow/process → after-save flow → async (emails, scheduled paths)

The problem in an old Org: you've got a before-save flow, two after-save flows, a Process Builder, a leftover Workflow Rule AND an Apex Trigger all firing on the same Object. Each Field update that touches the same record can re-enter that whole sequence. That's your recursion. That's why you hit "Too many SOQL queries" and CPU timeouts under load. It's not volume, it's re-entrant save cycles stacking up.

What to actually do:

• Clean up Validation Rule, Roll-up Summaries
• Clean your Flows: If you're updating a field on the SAME record that triggered the automation, use a BEFORE-save flow. No extra DML, no second save cycle.

Use AFTER-save only for what genuinely needs the saved record: creating/updating related records, emails, async work, subflows.

Target one before-save and one after-save Flow per object. Gate everything with entry conditions instead of spinning up a new Flow per use case. (Or think about Orchestration/APEX)

And the trap when migrating off Workflow Rules / Process Builder: don't port them 1:1 with the Migrate to Flow tool and walk away. A 1:1 port just rebuilds the same mess in a newer tool. The migration is your one good chance to consolidate.

Cleaning automation isn't only about deleting things. It's about respecting the save cycle.