Vue 2 to Vue 3 migration notes from product work

A Vue migration is rarely just a framework migration. In product code, it is usually a test of how well the team understands its own component contracts.

The first pass should be inventory. Which screens matter most? Which components are shared? Which plugins are blocking? Which flows are fragile because they depend on implicit reactivity or old lifecycle behavior?

I prefer to migrate from the edges inward. Start with leaf components and low-risk screens, then move toward shared layout, forms, tables, and stateful workflows. This creates useful learning before the team touches the parts that can break revenue or operations.

The Composition API is not a reason to rewrite everything. It is useful when logic needs clearer grouping, reuse, or testability. A simple Options API component that works and is easy to read does not need to become abstract just because the framework allows it.

The sharp edges usually show up in plugins, event contracts, v-model behavior, watchers, and global dependencies. Design-system components deserve extra care because a small behavior change there can leak into dozens of screens.

Testing should focus on product behavior, not migration ceremony. Can the merchant complete onboarding? Can an admin save settings? Can a table filter, paginate, and recover from errors? Those checks matter more than proving every component was rewritten in the newest style.

The best migration is boring to users. They should get a faster, more maintainable product without feeling the framework changed underneath them.