Migrating from AngularJS to Vue 3

Overview

Moving from AngularJS to Vue 3 is a full framework rewrite, not a data migration or an upgrade path - AngularJS itself has reached end of life, with its own project site stating support has officially ended and directing users toward modern Angular (a separate, unrelated framework) rather than offering a Vue migration path. There is no tool that converts AngularJS code to Vue 3, and unlike some other framework pairs, there's no in-process interop library either: AngularJS predates the modern component-tree conventions Vue 3 and its tooling assume, so both the component code and the build setup are typically replaced wholesale rather than incrementally upgraded. The one documented incremental route is running both frameworks side by side as separate micro-frontends while you rewrite feature by feature.

This guide covers moving from AngularJS to Vue — see each platform's release history and version notes on its technology page.

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

Get my plan

What transfers cleanly from AngularJS to Vue 3

  • AngularJS's .component() helper - described in its own docs as "a special kind of directive... suitable for a component-based application structure" and framed as the closer analog to modern component-tree architectures - has a direct structural counterpart in a Vue 3 Single File Component: template and logic defined together, giving each .component() a concrete rewrite target.
  • AngularJS's injectable service, documented as "reusable business logic independent of views," maps conceptually onto a plain Vue composable function or a Pinia store - both centralize logic outside individual components, even though Vue's version is imported directly rather than resolved through AngularJS's dependency injector.
  • Routing has a conceptual role-equivalent on each side: AngularJS's ngRoute module (or, more commonly in practice, the third-party UI-Router, described in its own repo as "the de-facto solution to flexible routing with nested views in AngularJS") maps onto Vue Router, the official router maintained by the Vue core team - the concept of a dedicated router with nested/dynamic routes carries across even though every route has to be reconfigured by hand.

What does not transfer

  • No AngularJS-to-Vue interop library exists. veaury, the interop library used for React-to-Vue-3 migrations, is explicitly React-and-Vue-3-only and doesn't mention AngularJS at all - and AngularJS's own project directs users toward Angular, not Vue, as its supported path forward.
  • No official or community-standard AngularJS-to-Vue codemod exists. AngularJS's own migration tooling story (ngUpgrade, hybrid apps) is entirely about moving to modern Angular, a different target framework than Vue.
  • Build and test tooling doesn't converge the way it does for some other pairs. AngularJS's own testing guide points to Karma and Jasmine, and many AngularJS apps were built without a module bundler at all, or with Grunt/Gulp/Bower - tooling that predates the Vite-first convention Vue 3's official scaffolding uses. An AngularJS app's build setup is typically replaced wholesale rather than incrementally upgraded.
  • AngularJS's automatic two-way data binding - where "the value of the expressions are automatically recalculated and the DOM is updated" whenever inputs change - has no equivalent that works the same way in Vue. Vue's reactivity requires explicitly declaring state with ref() or reactive(); nothing binds automatically without that declaration, so this is a structural rewrite, not a syntax swap.

Effort drivers

  • Whether the team can adopt a micro-frontend architecture at all - since no in-process interop library exists for this pair, single-spa (mounting AngularJS and Vue 3 as separate micro-frontends) is the only documented staged route; teams that can't take that approach face an all-at-once rewrite instead.
  • How much of the app depends on AngularJS's dependency-injected service layer and automatic two-way $scope binding, since both have to be restructured by hand - services into composables or Pinia stores, and every binding made explicit - rather than mechanically translated.
  • What build and test tooling the app currently sits on - a Grunt/Gulp/Bower setup, a bundler-less app, or Karma-and-Jasmine tests are typically replaced wholesale rather than upgraded, since there's no shared or converging tool between AngularJS and Vue 3 for this pair.
  • Whether the app uses ngRoute or the more commonly-used third-party UI-Router for routing, since both have to be manually reconfigured as Vue Router routes, with no automated conversion documented for either.

Recommended approach

Treat this as a full rewrite staged through a micro-frontend strangler pattern, since single-spa - confirmed by its own docs to support both AngularJS and Vue - is the only documented incremental route for this pair: mount a new Vue 3 micro-frontend alongside the existing AngularJS app and migrate route by route or feature by feature. There's no in-process interop library comparable to what exists for some other framework pairs, so component-level "run both at once" swaps aren't an option here - plan for the micro-frontend boundary to be the unit of migration, not the individual component.

Rewrite manually, mapping each AngularJS building block to its nearest Vue 3 structural counterpart: .component() definitions become Vue Single File Components, controller-plus-$scope logic becomes a <script setup> block using ref()/reactive() in place of automatic two-way binding, and injectable services become plain composable functions or Pinia stores imported directly rather than resolved through AngularJS's injector. Rebuild routing on Vue Router rather than trying to port ngRoute or UI-Router configuration directly.

Plan to replace the build and test tooling wholesale rather than upgrade it in place - move off Grunt/Gulp/Bower (or a bundler-less setup) and Karma-plus-Jasmine onto Vue 3's Vite-based scaffolding (npm create vue@latest) and Vue Test Utils, since AngularJS's tooling era simply doesn't converge with Vue 3's the way some newer frameworks' does. Because AngularJS itself has reached end of life with its own site directing users elsewhere for support, budget this as a genuine rewrite with a real timeline rather than a lift-and-shift, and prioritize migrating the parts of the app most exposed to running on an unsupported framework first.

FAQ

Can I run AngularJS and Vue 3 together during migration?
Yes, through single-spa - a micro-frontend framework whose own docs confirm support for both AngularJS and Vue. It mounts each framework's app as an independent micro-frontend on the same page, so you can bring up a new Vue 3 app alongside the existing AngularJS one and migrate route by route. There's no in-process interop library for this pair (unlike react-to-vue3, which has veaury), so single-spa's micro-frontend boundary is the practical staging unit, not the individual component.
Is there an automated tool that converts AngularJS to Vue 3?
No. No official or community-standard AngularJS-to-Vue codemod exists - AngularJS's own migration tooling only targets moving to modern Angular, a different, unrelated framework, not Vue.
What's the Vue 3 equivalent of an AngularJS service?
A plain composable function, or a Pinia store for anything that needs to be shared more broadly - both serve AngularJS's documented service role of "reusable business logic independent of views," just imported directly rather than resolved through dependency injection.
Why is migrating off AngularJS urgent?
Because AngularJS has reached end of life. Its own project site states that support has officially ended and directs users toward Angular (a separate, unrelated framework) rather than offering continued AngularJS support or a documented migration path to Vue.
Can I reuse my AngularJS build and test setup after migrating to Vue 3?
Not directly. AngularJS-era tooling - often Grunt, Gulp, or Bower, or no bundler at all, tested with Karma and Jasmine - predates the Vite-first convention Vue 3's own scaffolding uses, so the build and test setup is typically replaced wholesale rather than upgraded in place.

Ready to see what this actually takes?

Get my plan

Related migrations