unity-legacy-migrationlisted

# Unity legacy migration **Most old code should be left alone.** Migration competes with shipping and pays nothing back on its own — the game is not faster or less buggy because a class moved. "This is fine as it is" is a valid answer and usually the right one. **The project decides what "current" means.** Migrate toward the conventions this repo already has — its `STRUCTURE.md`, its contributor notes, the shape of its newest code — not toward the taste in this file or any other skill. Where the project has no opinion, do not invent one mid-migration: ask, or leave the old shape alone. This is the deliberate counterpart to the `unity-coding-habits` rule against restyling code you are passing through. That rule holds; this is what you do instead. | Reference | Read it when | |---|---| | [references/rename-and-move.md](references/rename-and-move.md) | Renaming or moving any file under `Assets/`, or a whole folder. | | [references/serialized-values.md](references/serialized-values.md) | Renaming a serialized field, adding a namespace, or moving a type between assemblies. | | [references/splitting-types.md](references/splitting-types.md) | Breaking one large `MonoBehaviour` into several components. | ## 1. Decide whether to migrate at all Migrate when one of these holds: you are about to do real work in that code anyway and its shape makes that work harder; it is actively breaking, like a deprecated API the project's next editor drops or a field name that now means the wron