Can Vue 2 be upgraded directly to Vue 3?

**Many applications can be upgraded in place, but it is not a one-command update.** The Vue 3 migration build can help identify incompatible APIs in eligible applications. Router, state management, build tooling, third-party components, and SSR frameworks still require deliberate compatibility work and testing.

Do we have to rewrite Vue 2 Options API components using the Composition API?

**No.** Vue 3 supports the Options API. Keeping stable Options API components is often the lowest-risk migration choice. Composition API can be adopted gradually for new code or components where reusable logic and TypeScript benefit from it.

Is Vuex required in Vue 3, or should we move to Pinia?

**Vuex 4 works with Vue 3, so a Vuex-to-Pinia conversion is not mandatory for the framework migration.** Pinia is the recommended state-management solution for new Vue applications, but converting stores should be scoped separately unless the existing store is already causing maintainability problems.

Will a Vue 2 to Vue 3 migration affect SEO?

**It can, especially for Nuxt, server-rendered, statically generated, or public client-rendered sites.** Preserve URLs and validate redirects, titles, meta descriptions, canonical tags, structured data, sitemaps, robots rules, status codes, rendered HTML, and hydration. A UI that looks correct in a browser can still have changed crawl or rendering behavior.

Can we keep our current Vue 2 component library and plugins?

**Only if each package has verified Vue 3 compatibility**. Some libraries offer upgrade paths, some require major-version changes, and some need replacement. Audit UI libraries, editors, charts, maps, payment components, directives, and internal packages early because unsupported dependencies can determine the migration strategy.

Vue 2 to Vue 3 Migration Guide

Overview

Vue 2 reached end of life on December 31, 2023, so a move to Vue 3 is usually a risk-reduction and maintainability decision rather than a visual redesign. Vue 3 provides an actively maintained framework, improved TypeScript support, better runtime performance opportunities, and a current ecosystem. It is not always a drop-in upgrade: the required work depends heavily on the app’s dependencies, build tooling, server-rendering setup, and use of deprecated APIs.

A migration can be performed incrementally with the Vue 3 migration build for many applications, or as a deliberate rebuild of selected screens and shared components. The safest plan starts with an inventory of packages, browser support requirements, rendering mode, custom directives, global plugins, and business-critical user journeys. Keep the existing API contracts and data stores stable where possible, then modernize framework code in controlled stages.

Both Vue 2 and Vue 3 are covered on the Vue technology page.

Want a plan tailored to your Vue 2 → Vue 3 migration?

Get my plan

What transfers cleanly from Vue 2 to Vue 3

Application data does not need to be converted merely because the front end moves from Vue 2 to Vue 3. Existing backend databases, REST or GraphQL APIs, authentication sessions, analytics data, CMS content, and uploaded assets can normally remain unchanged.
Most component templates transfer with modest changes. Core concepts such as components, props, events, computed values, watchers, slots, forms, and conditional rendering remain familiar.
Options API components are supported in Vue 3. A team does not have to rewrite every component using the Composition API to complete the migration.
Plain CSS, CSS modules, Sass, design tokens, and many existing component styles can be retained. A visual regression review is still necessary because changed component structure, third-party widgets, and CSS selector behavior can affect appearance.
Existing routing concepts and page URLs can be preserved. With appropriate router configuration and server rewrites, public paths, redirects, canonical URLs, and bookmarked links do not need to change.
Most API clients, validation libraries, utility packages, observability tools, and browser SDKs continue to work if they do not depend directly on Vue 2 internals.

What does not transfer

Vue 3 has a different application initialization model. Vue 2 patterns based on new Vue(), Vue.prototype, global filters, and some global APIs must be replaced with createApp(), app.config.globalProperties, component methods or computed values, and explicit app-level registration.
Vue Router 4 is the Vue 3 router generation. Router creation, history setup, navigation behavior, route matching details, and test setup need review. Do not assume a Vue Router 3 configuration can be copied unchanged.
Vuex 4 is the Vue 3-compatible release; Vuex 3 targets Vue 2 and does not run on Vue 3. Pinia is the recommended state-management library for new Vue applications, but adopting it is optional and should be treated as a separate state architecture decision.
Several template and component conventions changed, including v-model behavior, the removal of filters, .sync replacement patterns, event listener inheritance behavior, and some slot and transition behavior. The migration build can identify many of these issues, but manual fixes and tests are still required.
Third-party Vue 2 UI kits, date pickers, editors, chart wrappers, maps, payment widgets, and internal component libraries cannot be assumed compatible. Each must have a Vue 3 release, a supported replacement, or an isolation strategy.
If the application uses server-side rendering or static generation, the rendering framework is a major workstream. Nuxt 2 and Nuxt 3 have substantially different module, routing, data-fetching, deployment, and runtime conventions. A Vue upgrade alone does not safely upgrade a Nuxt application.
Vue 3’s reactivity model has edge cases that differ from Vue 2, especially around refs, reactive objects, watchers, array/object mutation assumptions, and libraries that inspect or mutate component instances. Complex forms, shared stores, and custom composition utilities need focused testing.
Legacy browser support may change. Vue 3 does not support Internet Explorer 11. Confirm supported browsers, embedded webviews, kiosk devices, and enterprise environments before committing to the migration.

Effort drivers

Dependency compatibility is often the largest unknown. Build a complete list of direct and transitive Vue plugins, UI libraries, proprietary components, browser SDK wrappers, and their Vue 3 support status before estimating the work.
The size and age of the component library matters more than the raw number of pages. Components using render functions, mixins, filters, custom directives, dynamic components, direct DOM access, or private Vue internals need more attention.
Build tooling may need modernization. Older Vue 2 applications commonly use Vue CLI and webpack configurations. Vue 3 can run with webpack, but many teams move to Vite. Combining a bundler migration, framework upgrade, and redesign increases delivery risk and should be phased when possible.
State management complexity drives testing needs. Review Vuex modules, persisted state, local storage schemas, cross-tab synchronization, permissions, checkout flows, drafts, and optimistic updates. Preserve storage formats or provide versioned migration logic so users do not lose in-progress work.
Authentication and integrations require end-to-end validation. Test login, logout, token refresh, SSO callbacks, consent managers, payment flows, support chat, feature flags, analytics, error reporting, A/B testing, embedded widgets, and file uploads in the Vue 3 runtime.
SEO effort depends on rendering mode. A client-rendered single-page app needs correct title, meta, canonical, robots, sitemap, structured data, redirects, and crawl behavior after deployment. An SSR or static site also needs server-rendered HTML, hydration checks, cache behavior, and route-by-route validation.
Theming work rises when the product supports white-label brands, dark mode, tenant-specific themes, or a large design-system layer. Validate CSS variables, Sass compilation, scoped-style behavior, deep selectors, portal or modal styling, RTL layouts, and all brand combinations.
Test coverage changes the risk profile. Existing unit, component, visual, and end-to-end tests can accelerate migration, while low-coverage business-critical applications require more manual acceptance testing and rollout safeguards.

Recommended approach

Start with a discovery and compatibility audit, not a code-wide rewrite. Document the current Vue version, build system, router, store, SSR or static-generation setup, supported browsers, deployment process, and every Vue-dependent package. Classify each dependency as Vue 3 compatible, upgradeable, replaceable, or blocked. Include internal shared packages and externally injected scripts.

Create a production-like migration branch or environment and establish a baseline: automated tests, key page screenshots, Web Vitals or performance measurements, JavaScript error rates, conversion and checkout paths, search-engine crawl samples, and rendered HTML for important public pages. Inventory all existing URLs and redirect rules before changing routing or server configuration.

For a standard client-rendered application, upgrade build dependencies and application entry points, then use the Vue 3 migration build where appropriate to surface incompatible runtime patterns. Resolve warnings systematically, beginning with shared components, application plugins, router, and state. Keep Options API components initially if that reduces change. Introduce Composition API and Pinia only where they produce a clear maintenance benefit; neither is a prerequisite for Vue 3.

Run the old and new versions against the same non-production APIs when feasible. Do not alter backend schemas, API payloads, authentication behavior, or persisted client-state formats simply because the UI framework changed. Where a client storage format must change, use explicit versioning and migration logic, with safe handling for invalid or stale data.

Treat Nuxt or SSR migrations as a separate plan. Validate server-rendered source HTML, status codes, redirects, canonical tags, metadata, structured data, sitemaps, robots rules, hydration warnings, cache headers, and route rendering for every high-value indexable page. Preserve URL structure unless there is an approved SEO redirect plan. Compare analytics and search-console signals after release rather than relying only on browser testing.

For theming, migrate and test the design-system foundation before page-level work. Confirm token generation, CSS variable inheritance, component overrides, dark mode, tenant branding, modal and overlay placement, and email or embedded-widget boundaries. Use visual regression tests or controlled screenshot comparisons for representative pages and themes.

Release behind a feature flag, by route, audience, or deployment environment when the architecture permits. Monitor JavaScript errors, failed API calls, hydration issues, route errors, conversion events, performance, and SEO crawl errors. Maintain a tested rollback path. Retire Vue 2 dependencies, compatibility mode, and duplicated code only after the Vue 3 path has demonstrated stable production behavior.

FAQ

Can Vue 2 be upgraded directly to Vue 3?: Many applications can be upgraded in place, but it is not a one-command update. The Vue 3 migration build can help identify incompatible APIs in eligible applications. Router, state management, build tooling, third-party components, and SSR frameworks still require deliberate compatibility work and testing.
Do we have to rewrite Vue 2 Options API components using the Composition API?: No. Vue 3 supports the Options API. Keeping stable Options API components is often the lowest-risk migration choice. Composition API can be adopted gradually for new code or components where reusable logic and TypeScript benefit from it.
Is Vuex required in Vue 3, or should we move to Pinia?: Vuex 4 works with Vue 3, so a Vuex-to-Pinia conversion is not mandatory for the framework migration. Pinia is the recommended state-management solution for new Vue applications, but converting stores should be scoped separately unless the existing store is already causing maintainability problems.
Will a Vue 2 to Vue 3 migration affect SEO?: It can, especially for Nuxt, server-rendered, statically generated, or public client-rendered sites. Preserve URLs and validate redirects, titles, meta descriptions, canonical tags, structured data, sitemaps, robots rules, status codes, rendered HTML, and hydration. A UI that looks correct in a browser can still have changed crawl or rendering behavior.
Can we keep our current Vue 2 component library and plugins?: Only if each package has verified Vue 3 compatibility. Some libraries offer upgrade paths, some require major-version changes, and some need replacement. Audit UI libraries, editors, charts, maps, payment components, directives, and internal packages early because unsupported dependencies can determine the migration strategy.

Ready to see what this actually takes?