![](\"https://accesto.com/images/icons/bulb.svg\"){kind=icon}
Welcome to our From AngularJS to Angular series - for teams still running AngularJS: why waiting is a risk, which migration approach fits your app, and what are the most common ways to do that in practice.Welcome to our From AngularJS to Angular series - for teams still running AngularJS: why waiting is a risk, which migration approach fits your app, and what are the most common ways to do that in practice.
TL;DR: Yes, but not in one move. AngularJS (1.x) and Angular (2+) are different frameworks and there is no automated AngularJS-to-Angular upgrade path. There are several ways to run old and new code side by side while you move, and we have used three of them on real projects: a hybrid with ngUpgrade (two frameworks in one app), a side-by-side rewrite behind feature flags (two apps, split by URL), and an embedded strangler (new Angular mounted inside a server-rendered legacy page). Which one fits depends on how the app is built. Before migrating the first screen, decide which router, rich-text editor and component library the finished application will use. We postponed all three, and each one added rework later.
\nOne of our AngularJS migrations started with 223 source files in the legacy app. By the time its replacement was ready, the legacy app had 519. It kept growing the whole time we were rewriting it.
\nWe have done this on three applications. Two were AngularJS single-page apps. The third was a framework-less PHP application where the frontend was HTML coming out of the backend. Not an AngularJS migration in the strict sense, but it answers a question we keep getting from teams whose app is not really a SPA either, so it stays in. Each of the three needed a different mechanism. There is no tool that migrates an application end to end. The numbers below come from our own repositories, including the parts that went badly.
\nAngularJS is built around $scope, the digest cycle and an injector that resolves dependencies by string name. Angular has classes, TypeScript, a compiler, reactivity through signals or RxJS. Some of the names overlap. The programming models do not. Controllers, directives and templates are framework-specific and have to be adapted. TypeScript, plain JavaScript and CSS that do not reach into the framework can often be reused as they are. A script or an AI tool can translate simple syntax, an ng-repeat into an @for block or a $http call into HttpClient, but no supported tool converts a whole application and preserves its behaviour.
Incremental migrations usually come in one of two broad shapes. Either both frameworks share one application, or the new application lives beside the old one. Our three projects used one version of the first and two versions of the second. The hybrid family alone has two documented variants. With UpgradeModule both frameworks bootstrap together. With downgradeModule() Angular starts lazily, once the first downgraded component is used. The URL split and the embedding can each be built in more than one way too.
On a whiteboard it looks clean. The problem shows up late.
\nOne of our projects is a B2B SaaS for PR teams. Two AngularJS 1.5 apps, a customer-facing client with 74 controllers and an admin panel with 193. In December 2020 a fresh Angular app started next to the old one, and the file counts above come from this project. Some features were built twice, once in each stack, because customers do not stop asking while you rebuild. Nineteen months in, the old app's header still did not know about the new routes.
\nWhatever mechanism you pick has to come with a rule about where new work goes. Ours ended up as new features in the new stack only, with critical fixes still going into the old app. The freeze took hold late. How soon you can enforce a rule like that depends on how much of your roadmap touches screens nobody has migrated yet. We now start it the day the new workspace exists.
\n@angular/upgrade/static runs both frameworks inside one application. Downgrading an Angular component lets AngularJS templates render it. Upgrading an AngularJS service makes it injectable in Angular code. You move one component at a time and the application stays one application, with one deploy and one session.
We did this on a team-planning SaaS. AngularJS 1.7, bumped to 1.8 along the way. About 166k lines in the legacy JavaScript and template directories, plus roughly 48k lines of AngularJS written in TypeScript left over from an earlier modernisation attempt, 161 controllers, 370 directives and 84 UI-Router states. The two peaks came at different times. Downgraded components reached 154 in October 2023. Downgraded injectables reached 80 in May 2024, when the component count was 150. Another 38 Angular services were exposed through a global registry on window, to AngularJS and to consumers outside Angular's dependency injection.
Most of the later boundary bugs here involved dependency injection and service readiness. One file, the mention plugin of the rich-text editor, failed with an \"Unknown provider\" error in 2021 and again in 2025, two different immediate causes four years apart. The file had the location of the framework boundary written into it. The boundary had moved. Twice.
\nUI-Router owned the route tree for most of the hybrid's life, shared by both frameworks through @uirouter/angular-hybrid. The first real Angular Router routes appeared in September 2024, with AngularJS still in the application, and the last UI-Router package left twelve months later, in September 2025. Some of those boundary problems reached users as routing glitches and inconsistent UI behaviour. The bootstrap races were our own doing rather than ngUpgrade's. The global registry carried services and said nothing about whether the one you wanted existed yet.
Taking AngularJS out removed the largest compatibility constraint in the project and made a concentrated upgrade possible. Nine sequential update commits between 5 and 16 January 2026 took the application from Angular 12 to Angular 21, one ng update each, because Angular's supported update path goes one major at a time. The chain reached the main line in May 2026. That batch went fast. Whether the majors after it stay this easy, we will find out.
The price of the hybrid is that the boundary needs an owner for as long as it lives, which is a bad trade for a small team on a big app. The mention plugin is what that price looks like four years in.
\nThis pattern is for a legacy frontend that is mostly server-rendered HTML, with AJAX endpoints returning further HTML fragments. PHP, .NET, Rails, or AngularJS 1.x sprinkled into server-rendered pages, which is how a lot of AngularJS was actually deployed. There is no SPA to hybridise with. Ours was the framework-less PHP variant, with no usable API to build a new frontend against either. We added endpoints screen by screen.
\nThe legacy page shell renders a container for the new Angular app next to the one the legacy loader has always written into, and a URL prefix (/modern/) decides which of the two is in front. Screens move one at a time with a flag in the database. The bridge script loads Angular on the first modern navigation, so a page that stays legacy does not pay for the bundle. Session, backend and deploy stay as they were.
We run this in a care-management SaaS for German healthcare providers. About 100 navigable screens of framework-less PHP, 15+ years old, in daily use by care teams. Fifteen months in, 23 screens have been rebuilt on Angular, each controlled by one database row and reversible without a deploy. The old screens' code has not been modified. Four things changed in the legacy app: the page shell (the Angular container and the bridge script), the menu renderer, about thirty lines in the AJAX loader and one global flag.
\nThe hard part is the bridge between the two apps. Angular bootstraps on a URL that is usually not its own, and both sides want the address bar. In our setup only the bridge writes to browser history, and the Angular container appears only after a navigation has completed. Every trap we hit sat on that seam: legacy href=\"#\" menu links whose history entries the Angular router tried to interpret, relative AJAX paths resolved against /modern/, page reloads on Angular URLs, and two writers with different HTML-entity conventions in the same tables.
The bridge has its own post, with the code, browser history, reloads, failed navigations and the two wrong turns we took first, an iframe and a global XHR monkey-patch.
\nIf the app is already a SPA, use way 1 or way 2.
\n| Your situation | \nMechanism | \n
|---|---|
| One big AngularJS SPA, shared state everywhere, cannot split by URL | \nHybrid (ngUpgrade) | \n
| AngularJS SPA that can be frozen, backend has usable APIs, customers can be switched in groups | \nSide-by-side with feature flags | \n
| Server-rendered legacy (PHP, .NET, Rails, or AngularJS inside server pages), AJAX returns HTML, dozens to hundreds of screens | \nEmbedded strangler | \n
| Small app, roughly under 20 screens, few custom directives (a heuristic, not a threshold) | \nSide-by-side, or honestly a rewrite with a freeze | \n
We start the audit with this inventory: screens or router states, controllers and directives, services, third-party AngularJS libraries split into \"has a replacement\" and \"needs a rebuild\", and lines of templates. Those numbers narrow the options. The rest usually decides: deployment topology, authentication, how much state the screens share, what test coverage exists and how fast the product itself is changing.
\nThe three above are the ones our own projects ran. The list of options is longer:
\nstrictDi, TypeScript, characterisation tests, deleting dead features;downgradeModule(), each with its own injector;Our post on the ngUpgrade project goes through the ones that apply to hybrids.
\nThree technical decisions matter early.
\nState management is a smaller call, and it is worth making while you are in there anyway. Services with signals may be enough, larger workflows may justify a store like NgRx, and the two are not mutually exclusive.
\nThen there is the part that is not technical. Somebody needs the migration as a primary responsibility, and the work needs an end date. Both migrations that took years ran next to the product roadmap with no deadline and, as the team remembers it, two or three people on them. That setup was the main source of delay, although our boundary and router choices added work of their own.
\nThe mechanical part of a migration got much cheaper. An inventory of controllers, directives, services and routes with a dependency graph is quick work now. So is translating ng-repeat and ng-if templates into Angular control flow, rewriting $http and Restangular services into typed HttpClient calls, or generating characterisation tests for existing behaviour before anyone touches it. On bounded work like that we now budget hours where we used to budget days. Every generated piece still gets reviewed, and the characterisation tests exist because a generated translation can pass a quick review and still change behaviour.
Everything around that work is unchanged: choosing the mechanism, the order of screens, where the boundary between old and new runs, the router and editor decisions above, the design of the per-screen switch and its rollback, the teardown plan. A model will draft the translation. Which behaviour may be dropped, or which database change makes a rollback unsafe, we still work out ourselves.
\nCan AngularJS be migrated to Angular directly?
\nNo. There is no automated upgrade path. Migration means moving code piece by piece with one of the three coexistence mechanisms above, and the application keeps running during the move.
\nIs ngUpgrade the recommended way to migrate AngularJS?
\nIt is Angular's official interoperability library for AngularJS hybrids (documentation), which is not the same as the right strategy for every application. It fits large SPAs that cannot be split by URL. A boundary that stays between the frameworks for years can keep producing integration work, especially when services cross it through custom mechanisms such as our global registry, and that is why the hybrid needs an owner and an end date.
\nCan we keep releasing features during an AngularJS migration?
\nYes, and the rule that worked was to release them into the new stack only. In our projects, continuing to ship features into the old app while replacing it was the main reason the finish line kept moving.
\nHow long does an AngularJS migration take?
\nIn the projects we have seen, the setup around the migration mattered more than the size of the application. The two that ran next to the product roadmap with no deadline took years. We do not quote a duration before inventorying routes, dependencies, test coverage and the rate of product change. One thing we do plan from the start is an early production milestone: one complete, user-facing screen served by the new stack behind a switch, rather than only a new workspace.
\nWhat happens to ui-router, angular-material, ui-bootstrap and textAngular?
\nEach one is mapped in the audit to a modern replacement or a rebuild. Routers and rich-text editors are decided first, because they are the ones that drag on if left for later.
","timeToRead":12,"frontmatter":{"title":"Can you migrate AngularJS to Angular? Three ways to do it","tags":["angular","modernization","a2a"],"author":"amadeusz","categories":["for-developers"],"dateUpdated":null,"customTopics":[["Angular Tooltip Directive - Part 1","/how-to-create-angular-tooltip-directive","blog"],["Angular Tooltip Directive - Part 2","/angular-tooltip-directive-part-2","blog"],["How to improve your code readability?","/how-to-improve-your-code-readability-useful-clean-code-ideas-to-know","blog"],["Drag and Drop Angular Guide","/drag-and-drop-angular","blog"]],"customCTA":["Join the team where quality matters","https://accesto.com/career/","Join now"],"customContactCTA":["Join the team where quality matters","Be proud of your code and enjoy your life, great minds are always welcomed","Join now","https://accesto.com/career/"],"customContactCTAIcon":null,"heroImage":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAKCAIAAAA7N+mxAAAACXBIWXMAAAsTAAALEwEAmpwYAAABsklEQVQoz2Pg5vIjiHggiNufh8sfWZyBhyeYAOIO5uYK5OYJ5uYL5eEP4eUL4+YGCQIRAx9PBB9vJD9vJISEMPh4I+BsQbF4bcd+A5deI4+JGu7zxDTyJDTzhcQS+PijGPh5Y7k4ozjZo3i4ork4ojg5IoFcbq5oboggb5yQXJ6m6zQN9xnarn3KrjMUzOtUTGskVfIERJOBmpN0tEtNjCtVVQqMDCqMDSv0dcvUVAq0NYvNzKq1DSrltUq0bcr1HcpNQmc4ll6Wtm6RsWwS16kQksoBak7T16u2sW420Ks2M6kz0K82NqzV1CiXksiVkyuUUiiW0SjXtGlQNa808J1kX3BaxaFHw65TSqtaWKaAQYg/R5A/W1gwV0QoD0gK8ucICYBIAb4sft4sQZF8caUKe4/auKq9TnkHDRyqZC065Ky7pNRrhCWLGYQFC4QECgT5ISgfyIYgoDhISrBQXLbcxqkhIH2zU/IOfZsmZeN2LYtuVe0mYZEiBhGhMjxIWLBUVLhMRrZeTLJSRrFOUrZeSKxSSLhMSKAUKMUgKlyNH4kIVQsLVooIVQkLVQHZyFIACjyA5W3ZlvwAAAAASUVORK5CYII=","aspectRatio":1.9736842105263157,"src":"/blog/static/6401366a5f41f489fc82fc51b0f19228/f3583/angularjs_migration_hero.png","srcSet":"/blog/static/6401366a5f41f489fc82fc51b0f19228/630fb/angularjs_migration_hero.png 300w,\n/blog/static/6401366a5f41f489fc82fc51b0f19228/2a4de/angularjs_migration_hero.png 600w,\n/blog/static/6401366a5f41f489fc82fc51b0f19228/f3583/angularjs_migration_hero.png 1200w,\n/blog/static/6401366a5f41f489fc82fc51b0f19228/7adbf/angularjs_migration_hero.png 1660w","sizes":"(max-width: 1200px) 100vw, 1200px"}},"publicURL":"/blog/static/6401366a5f41f489fc82fc51b0f19228/angularjs_migration_hero.png"}},"fields":{"date":"2026-11-03"}},"authorImage":{"childImageSharp":{"fluid":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAGQABAQADAQAAAAAAAAAAAAAAAAQBAgMF/8QAFwEAAwEAAAAAAAAAAAAAAAAAAAECA//aAAwDAQACEAMQAAABpxPI79RurHjOJ3AP/8QAGxABAQEAAgMAAAAAAAAAAAAAAQIDAAQREhP/2gAIAQEAAQUCE5OjoNBzSfTLOiE62KTB8tMJrQvwf//EABoRAAEFAQAAAAAAAAAAAAAAABEAAQMQEiL/2gAIAQMBAT8BaLnRQv8A/8QAFREBAQAAAAAAAAAAAAAAAAAAESD/2gAIAQIBAT8BY//EAB4QAAIBAwUAAAAAAAAAAAAAAAABEQIhQRASMWFx/9oACAEBAAY/AkzzSiMovxklZ7Ka7ztJc3Ekkf/EABoQAQADAQEBAAAAAAAAAAAAAAEAESExYaH/2gAIAQEAAT8hwjlcIgxLZcZq/s1FdveRGW1QvYRBTVxcKiA3mTpI7djVgCif/9oADAMBAAIAAwAAABDLH4L/xAAYEQADAQEAAAAAAAAAAAAAAAAAAREQYf/aAAgBAwEBPxCtkXCivP/EABkRAAEFAAAAAAAAAAAAAAAAAAAQESExQf/aAAgBAgEBPxCzEGp//8QAIBABAAMAAQMFAAAAAAAAAAAAAQARITFBUcFhcZGh0f/aAAgBAQABPxCqCi/J8s2GWDGMvIjVuDzOJ/WVxR8/U9GlNrLL7Q9xAs0esuMIHAxhNOsJQ4fyDEGCnCvef//Z","aspectRatio":1,"src":"/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/ea649/amadeusz.jpg","srcSet":"/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/b1092/amadeusz.jpg 11w,\n/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/1d7ec/amadeusz.jpg 21w,\n/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/ea649/amadeusz.jpg 42w,\n/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/1c2ab/amadeusz.jpg 63w,\n/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/567fa/amadeusz.jpg 84w,\n/blog/static/3a9d8eb64c85cd020e98d23f31ca0336/f4ba4/amadeusz.jpg 1536w","sizes":"(max-width: 42px) 100vw, 42px"}}}},"pageContext":{"slug":"/angularjs-three-ways/","authorImagePath":"amadeusz.jpg"}},"staticQueryHashes":["1607616503","473848531"]}