Do not get carried away and create hundreds of refactorings! It is better to "simulate a little, refactor a little".

Try to limit the impact of individual refactorings. Move and rename a package at the top of the hierarchy might have severe consequences on the code base and are most likely high-risk operations during implementation.

If a package or class file gets renamed to a different name than specified in the refactorings, the refactorings are no longer applicable. There might be a chance in the future to semi-automatically update refactoring definitions based on the project's history, but we do not know when this will be implemented.

Work with only a few virtual models.

Note that in the IDE integrations, the standard "Modifiable.vm" is always applied and currently cannot be changed.

Virtual models are great for experimenting with refactorings in isolation. But, since refactorings are not synchronized between virtual models, it is recommended to have one "main" model that contains approved refactorings and integrate the experiments as frequently as possible. If the same compilation unit is affected by refactoring sequences in different virtual models, implementing the refactorings of the first model will make the refactorings of the second model "inapplicable". We plan to improve the exchange of refactorings between virtual models in future versions.

Section 20.1.7, “ Execute Refactorings in Eclipse ”