Search for ->fetch( in a project with old Kohana code and count the hits. A method call on a model, a comment, a line in a test fixture, an unrelated class that happens to have a method with the same name. That is what regex refactoring looks like. Regex does not know a method call from a string literal.
Rector does. A young tool I found this month: it parses PHP into an AST with nikic/php-parser, applies transformation rules, prints the code back. Rename a class across the whole project. Change a method call, add an argument everywhere. The AST sees that this fetch is called on that type and touches only those places. Mechanical change becomes exact.
The workflow that makes sense to me: run one rule, run the tests, review the diff. The review of a machine-made change is boring, and boring is what you want here. You review the rule once, not a thousand changed lines one by one. Attention goes to the two places where the rule did something unexpected.
I think about this from the position of someone with Kohana and Symfony code still in production. A framework upgrade is maybe ninety percent mechanical renames and signature changes. That ninety percent is why upgrades get postponed for years. If a machine takes the mechanical part, what remains is the actual decisions, and that part was never the problem.
The tool is early and rough. Rules cover a narrow set of cases, you will hit bugs, and I have not run it on anything that matters yet. Fear of regex was my reason for years. Fear of a new tool is a different reason with the same result.
The upgrade I keep postponing is still postponed. The excuse just got weaker.