An editor launching natively on a new processor is an encouraging milestone. It is also the beginning of a compatibility exercise that extends well beyond whether an empty scene opens.
Unity's Apple Silicon Editor preview announcement puts that exercise within reach. The word preview matters. These builds offer a way to explore the native environment, rather than a reason to assume every part of an existing production setup is ready to move.
A Unity project combines several kinds of software. Managed scripts are one part. Native plugins, external tools, editor extensions, importers and platform build steps are others. A project can appear healthy until a rarely used menu item loads a binary built for a different architecture.
That is why I would start with an inventory of dependencies. Which packages include native libraries? Which tools run outside the editor? Which parts of the build assume a particular path or executable? The objective is to find the places where the editor relies on more than its own code.
Architecture also has several meanings in a development workflow. The processor running the editor is one choice. The platform and architecture of the game being built are other choices. A native editor does not automatically make every output target available, nor does it prove a native plugin is compatible with the intended player.
The first migration test should be reversible. Open a copy of the project with a clearly identified editor version, let it import, and record any package or asset changes. Otherwise an experiment can quietly alter the project that still needs to work in the established environment.
I would include the unglamorous tasks in that test: importing a representative asset, entering play mode, using custom editor windows, building the actual target and launching the result. An empty project benchmark answers a different question from a project that depends on a capture plugin or a custom image importer.
Performance comparisons need the same care. First imports and warm imports are different workloads. A compilation bottleneck may not behave like a rendering bottleneck. Comparing unlike states can produce an impressive number that explains very little about everyday use.
There is a useful payoff even when the preview is not yet suitable for a particular project. It forces dependencies to become visible. A plugin that has been quietly essential for years is easier to maintain once its platform assumptions are documented and its role can be tested separately.
I see the preview as an opportunity to prepare that knowledge. Keep the established environment available, identify the components that need attention, and make the migration decision based on the project's real path from source to build. Native execution is valuable, but a dependable development environment is the result that makes it valuable to work with.