At $WORK we have "code guardians" whose responsibility is do to this kind of migrations strategically in the background. The intent is that most other developers should not need to do any (or very little) extra work beyond the task they are actively working on.
There's no "tool replacement" going on here.
Also, usually tools like Ruff can be configured to enable/disable project-specific formatting rules (via a config file), allowing you to suppress the defaults you disagree with, or whose consequence you don't want to deal with _right now_. Some tools might even support suppressing specific rules per-file, so you can migrate codebase over time instead of in one go.
Having a config that explicitly defines the rules enforced in the project is really useful, and perhaps even crucial the bigger the project grows.
You will probably have to do it all over again when these guys release even newer and shinier 0.17.0, with even more rules.
I can't understand how the option of not feeding the bot eludes people.
A single commit after a tool change. I don't see the problem.
When you replace tool x with tool y, you need to fix your code, because these tools do not agree on what your code should look like, and what was acceptable for tool x simply isn't for tool y.
One of these changes I mentioned brought a massive reformatting of all code base, as the new tool failed 'import' statements unless they were in alphabetical order.