How Long Does Vue 3 Migration Take?

Quick answer: After inventory, plan on about 2–6 weeks for a small, well-tested Vue app, 6–16 weeks for a medium production app and 4–9+ months for a large Vue or Nuxt product.

You plan for a month. The first update goes fine. Then the surprises show up: add-ons that only work with Vue 2, shared data code nobody owns and pages that need rework.

That is how a simple upgrade becomes a release risk. These are VueSquad planning bands, shaped by our Vue/Nuxt scoping model. Use them as a starting point, then tighten the plan after inventory.

Written by Sudipto Mondal, Senior Software Engineer at VueSquad. Sudipto is a full-stack developer with 5+ years of experience in SaaS platforms, eCommerce systems and custom software.

The short answer: plan by app size and Vue-specific risk

You need a timeline your product team can staff, not a guess based on lines of code.

Official Vue docs explain tools and breaking changes. They do not promise one duration for every app. We group Vue migrations by component count, dependency risk and release shape before we assign engineers.

One engineer's week is not always one calendar week

If one engineer works only on the migration for a week, that is one focused week of work. The calendar can still stretch because code review, QA, product answers and release windows take time too.

Example: say your app lands in the medium band. One senior engineer may spend most of a quarter on it. Two engineers can shorten that, but they still wait on product decisions, test fixes and deployment reviews.

When to add contingency

Add contingency when the app relies on Vue 2-only packages, lacks end-to-end coverage or uses Nuxt SSR heavily. Vue is past its official Vue 2 support window; Vue’s FAQ names December 31, 2023 as the date official support ended for Vue 2 in its support policy answer.

Estimate dependencies first, tests second and files third. Lines of code matter only after you know what must be replaced.

A useful example is Craft Music, a content-heavy marketing site with teacher profiles, city landing pages, articles, testimonials and lesson-request forms. We moved it from Nuxt 2.15 and Vue 2 to Nuxt 3.10 and Vue 3.4 with one VueSquad engineer, while the client’s developer reviewed and merged work and the client kept editing CMS content.

Before migration, the app had 42 pages, 26 components, 6 layouts, 10 plugins, 263 content files, about 510 media files and about 6,700 lines of code. After migration, it had 38 pages, 38 components, 1 plugin, 272 content files and about 6,900 lines of code.

The work took about one week. Commits ran from February 20 to March 1, 2024, the branch was merged on February 27 and February 29, and final fixes landed on March 5.

The biggest blocker was Nuxt Content v1 to v2 markdown rendering. Thirteen of 63 developer commits in that period went into removing document-driven mode, dropping the content string renderer and switching to markdown-it with v-html for bios, intros and testimonials.

The next issue was prerendering and hydration. Six commits went into that path before all pages prerendered on February 29. The client also published CMS content to main, so main had to be merged into the migration branch several times.

What changes in Vue 3 that affects the estimate

The migration gets longer when your app depends on Vue 2 behavior instead of ordinary component code.

The Vue 3 migration build is a Vue 3 build with Vue 2-compatible behavior and runtime warnings for changed or deprecated features. It runs in Vue 2 mode by default, and you can tune compatibility per component.

That makes it useful for finding real blockers in a running app. It does not remove the need to fix them.

Use the migration build to find real compatibility issues

The official migration flow starts with tooling updates. That includes Vue 3.1, matching @vue/compat, @vue/compiler-sfc in place of vue-template-compiler and vue-loader ^16.0.0 for custom webpack setups.

One common breaking change is the global Vue API. Vue 3 moves app-wide APIs to the app instance, and Vue.use() is replaced by app-level installation.

// Vue 2
import Vue from 'vue'
import App from './App.vue'
import router from './router'
import AnalyticsPlugin from './plugins/analytics'

Vue.use(AnalyticsPlugin, { key: 'public-key' })

new Vue({
  router,
  render: h => h(App)
}).$mount('#app')

// Vue 3
import { createApp } from 'vue'
import App from './App.vue'
import router from './router'
import AnalyticsPlugin from './plugins/analytics'

const app = createApp(App)

app.use(router)
app.use(AnalyticsPlugin, { key: 'public-key' })
app.mount('#app')

That change looks small. In a mature app, it can touch analytics, feature flags, auth, i18n, error reporting and internal plugins.

Do not turn this into a full Composition API rewrite

Moving to Vue 3 does not force every component into Composition API on day one. If an Options API component works and is not blocking migration, leave it alone.

Fix compile-time errors first. Then handle runtime warnings, emitted events, filters, directives, async components and build tooling.

If you also move Vue CLI to Vite, treat that as separate scope. The official Vue documentation states that Vue CLI is now in maintenance. It is no longer recommended for new projects, and Vite is the recommended build toolchain for Vue 3 work in the migration recommendations.

The checklist that turns a guess into a Vue migration estimate

A good estimate starts with inventory. You cannot plan the migration if you do not know which packages and flows control the risk.

Before promising a date, count what can break. Use this checklist when you scope the work. If you need support for the implementation path, start with our Vue 2 to Vue 3 migration planning.

Score risk before promising a date

Low risk means most dependencies support Vue 3, tests cover key flows and the app has little custom infrastructure. Medium risk means a UI library, Vuex modules or build tooling need planned changes.

High risk means Nuxt SSR, old plugins, missing tests and active feature work collide. Ask one hard question: can the team pause changes in the files being migrated?

If not, you need branch ownership, merge rules and smaller pull requests. Scope the work before asking for outside Vue 3 migration help.

We do not assign engineers until we know these answers:

• Current Vue 2 version.
• Total pages and routes.
• Approximate number of components.
• package.json and dependency list.
• Build setup: Vue CLI, webpack, Nuxt or another setup.
• UI library: Vuetify, BootstrapVue, Element UI, custom components or another option.
• State management: Vuex or another store.
• Major third-party Vue 2 plugins and packages.
• JavaScript or TypeScript.
• Existing unit and E2E tests, plus coverage of core flows.
• Custom directives, mixins, filters, event bus or other Vue 2-specific code.
• Required browser support.
• App shape: SPA, SSR/Nuxt or another setup.
• Whether functionality and UI must remain exactly the same.
• Whether scope is migration only, or also Vite, Pinia, Composition API, <script setup>, refactoring and dependency upgrades.
• Repository access for a technical audit.

The most important question is simple: do you want a Vue 3 compatibility migration or a full modernization? That single answer can change staffing and timeline more than the component count.

Nuxt 2 to Nuxt 3 usually takes longer than Vue-only

Nuxt migrations need a bigger plan because you are changing framework architecture, not only component behavior. For Nuxt-specific staffing and scoping, use our Nuxt migration support.

Nuxt describes Nuxt 3 as a complete rewrite of Nuxt 2. The migration can include Vue 2 to Vue 3, Composition API and script setup, build-tool changes, server architecture and Nitro.

Use Nuxt Bridge when it reduces release risk

Nuxt Bridge is a forward-compatibility layer for using many Nuxt 3 features in a Nuxt 2 app. The Bridge instructions show Nuxt ^2.17.3 in the setup.

Use Bridge when it lets you land changes gradually and keep releases small. Do not use it as a long-term parking place. It needs an exit plan.

Do not assume @vue/compat solves Nuxt 3 migration

Nuxt’s migration configuration docs say it is not currently possible to use the Vue 3 migration build with Nuxt 3. That changes the estimate for many teams.

Nuxt workstreams include module compatibility, pages and layouts, dynamic route filenames, runtime config, plugins, middleware, server APIs and CommonJS imports. The docs also tell teams to move Vue app process.env usage to useRuntimeConfig.

Estimate Nuxt as a framework migration. If the app has SSR, hydration-sensitive pages or SEO revenue pages, build a calendar plan with rollback controls.

Failure modes that add weeks

Most slips have a clear smell. Name it early, and the fix is cheaper.

Community threads are useful leads, not benchmarks. The same pattern shows up in real product work: the core Vue update is often less risky than UI libraries, plugins, SSR behavior and tests. On products like TaskGrid, where Nuxt, real-time collaboration, custom drag-and-drop, Slack, GitHub and Stripe all meet in one app, you can see why migration risk lives at integration boundaries.

The build passing is not the finish line

A passing build means the compiler accepted your code. It does not prove SSR output, analytics, permissions, redirects or form edge cases still work.

For Vue-only apps, fix compile-time errors first, then runtime warnings, then browser regressions. For Nuxt, add SSR output, route behavior, runtime config and deployment checks to the same definition of done.

Who should do the migration, and what it costs

Staffing is a delivery decision. Pick the model that matches product risk and your team’s available attention.

Public hourly rates for senior Vue migration specialists are not reliable enough to use as a benchmark here. Ask each vendor for the same inputs: engineer count, billable hours, rate, QA scope and release support.

Use plain formulas:

Monthly cost = engineers × monthly rate

External project cost = engineers × billable hours × rate

Calendar duration = focused work ÷ available focused capacity, adjusted for review, QA and release windows

Use your own team when product knowledge matters most

Your team knows the strange parts: permission rules, old customer configs, analytics events and admin flows. If they have Vue 3 experience and can protect migration time, in-house can be the safest choice.

The danger is context switching. A migration that shares owners with feature work often dies by small conflicts.

Bring in senior Vue help when capacity or migration experience is the bottleneck

VueSquad is one option for teams that need senior Vue and Nuxt engineers inside their existing workflow. Engineers work in your GitHub, GitLab, Linear, Jira and Slack setup.

VueSquad’s Full-Time Senior Vue Engineer plan is $2,499 per month for 160 hours per month. The Part-Time Senior Vue Engineer plan is $1,499 per month for 80 hours per month.

Every plan has monthly billing, a flat rate, no onboarding fees and no minimum commitment. You can pause or cancel anytime, clients meet and approve the engineer before onboarding, and teams start within 48 hours in most cases. See VueSquad pricing and engagement models.

If you need multiple engineers, the Dedicated Vue Squad has custom pricing, engineering-lead oversight, shared architecture and coding standards, sprint planning and weekly reporting.

A practical Vue 3 migration plan for your next sprint

The next sprint should reduce uncertainty, not create a giant branch nobody can review.

Pick the migration shape before writing code

Choose one of three shapes:

1. In-place migration for small Vue apps with compatible dependencies.
2. Staged migration for most production Vue apps and eligible Nuxt 2 apps.
3. Rewrite only when product architecture must change beyond Vue.

A rewrite feels clean. It also hides parity risk: SEO, analytics, browser quirks, permissions, error states and admin behavior.

Our senior Vue engineers usually migrate in place when the app is stable, the architecture is still healthy and most dependencies have Vue 3 paths. That keeps product behavior visible and reduces parity risk.

Start fresh with Vue 3 or Nuxt 3 when the app has heavy technical debt, outdated libraries, poor structure or the migration would touch most of the code anyway. In that case, the migration is already a rebuild; call it that before you estimate it.

Ship migration work in reviewable slices

Use this sprint plan:

1. Run the inventory and risk score.
2. Define parity: routes, flows, SSR output, analytics, permissions and deployment.
3. Create the migration branch and freeze only files with migration ownership.
4. Turn on the migration build for Vue-only apps where it applies.
5. Fix compile-time errors first, then runtime warnings.
6. Regression test core flows, SSR output, analytics, permissions and deployment.
7. Release behind normal rollback controls.
8. Stabilize before starting optional refactors.

Plan your next move

If your app is small and well-tested, start with the inventory and run the migration in tight pull requests. If your product has Nuxt, SSR, a Vue 2 UI library or weak regression coverage, build a staged plan before changing packages.

For senior help inside your existing workflow, start by listing the risks you need covered. Then talk to VueSquad about your migration plan when you know where your team needs support.