Generic Plugin Migration Methodology

A disciplined procedure for moving a plugin across an upstream release that may contain breaking changes. Everything here is framework-agnostic: no product names, no version numbers, no API identifiers. Pair it with the upstream project's own changelog and release notes whenever those exist.

0. Ground rules

• Never migrate blind. If you have not read the upstream changelog for every version in the corridor (start → target, inclusive), you are guessing.
• Inventory before edits. A written list of what the plugin touches beats discovering breakage one crash at a time.
• Change one layer at a time, and keep the old install runnable until the new one is proven (side-by-side installs, separate data directories).

1. Inventory the coupling surface