--- title: Migrating the MAAS UI from AngularJS to React description: MAAS (metal as a service), is a Canonical product which allows for very fast server provisioning and data centre management. Around 2014, work began to build a rich UI for MAAS, primarily using the AngularJS JavaScript framework from Google. AngularJS today is in long term support (LTS) and due to reach end-of-life in 2021. This […] url: https://canonical.com/blog/migrating-the-maas-ui-from-angularjs-to-react?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [Kit Randel](https://canonical.com/blog/author/blr "More about Kit Randel") 6 December 2019 # Migrating the MAAS UI from AngularJS to React [angularjs](https://canonical.com/blog/tag/angularjs) [front-end](https://canonical.com/blog/tag/front-end) [MAAS](https://canonical.com/blog/tag/maas) [react](https://canonical.com/blog/tag/react) [sc:snap:maas](https://canonical.com/blog/tag/scsnapmaas) --- Share the article [MAAS (metal as a service)](https://maas.io/), is a Canonical product which allows for very fast server provisioning and data centre management. Around 2014, work began to build a rich UI for MAAS, primarily using the [AngularJS JavaScript framework](https://angularjs.org/) from Google. AngularJS today is in [long term support (LTS)](https://docs.angularjs.org/misc/version-support-status) and due to reach end-of-life in 2021. This year we began the work of transitioning away from AngularJS in anticipation of this impending EOL to more contemporary tooling. ## Evaluating Angular vs React Google’s recommended upgrade path for applications built in AngularJS is to transition to the [Angular](https://angular.io/) framework. Despite the similarity in naming, Angular is very different from AngularJS architecturally, and the migration process is non-trivial. While [components](https://docs.angularjs.org/guide/component) (allowing for the now ubiquitous uni-directional data architectural pattern) were later backported from Angular to AngularJS, most of MAAS UI predated this and consequently migration to Angular would require significant app-wide refactoring. Since the inception of the MAAS UI, a number of other products had been built at Canonical using [React](https://reactjs.org/). As we had developed significant experience using React, and tooling in the surrounding ecosystem, ultimately it made more sense to invest in transitioning the MAAS UI to React rather than Angular. This choice conferred additional benefits, such as standardising our build and testing infrastructure, and allows for component reuse across products. We also just generally enjoy working with React, and feel that the most significant developments in web UI technology are happening within the React ecosystem ([hooks](https://reactjs.org/docs/hooks-intro.html), [concurrent mode](https://reactjs.org/docs/concurrent-mode-intro.html), [suspense](https://reactjs.org/docs/concurrent-mode-suspense.html), [CRA](https://github.com/facebook/create-react-app)). ## Migrating to React A number of potential approaches were considered for the migration, big-bang, in-situ and hybrid. ### Big Bang As delightful as it is to work on a greenfields project, rewriting the entirety of the MAAS UI, particularly while still delivering features and bugfixes for our supported product in one go, was simply not feasible. ### In-situ An in-situ migration would involve rendering new react components within the existing AngularJS code, using a library such as [react2angular](https://github.com/coatue-oss/react2angular). While this may initially feel like the path of least resistance, it presents essentially the same issue as migrating to Angular – requiring that the AngularJS code is architecturally aligned with React, using uni-directional data flow and components. Significant refactoring to a codebase that we ultimately intended to replace, felt like a questionable use of time. ### Hybrid We eventually settled on a hybrid approach to migration, which involved creating an entirely new react-redux application, initially implementing a portion of the MAAS UI (settings and preferences in MAAS 2.7), and routing between the legacy and react app from Django. ## UI Codebase Separation As part of the work to transition to a hybrid application, we took the opportunity to separate the MAAS UI codebase from MAAS core. While this work shouldn’t be obvious to users of MAAS, it has provided a number of benefits to our development teams that will help us continue to build a great product. We also took the opportunity to make UX improvements to the Settings & Preferences experience as we migrated to React. ### Benefits Separation of the UI codebase from MAAS core has provided a number of benefits: * Better separation of concerns – MAAS core now exclusively provides APIs. * Faster tests – MAAS core CI is now faster. * Fit for purpose – build and configuration tooling can be better tailored to the needs of each project. * Team agility – more flexibility for both the UI and Core engineering teams. * Easier QA – designers are now able to point their development UI at a persistent MAAS server, rather than setting up and configuring MAAS on their own hardware. Designers can now point their *maas-ui* at a remote MAAS. ### Process Before (Single repo – UI in AngularJS & Django) ⟶ After (Multiple Repos *maas-ui*, *maas-core* – UI in Angularjs & React) The AngularJS UI was migrated from the MAAS core codebase, to a project called *legacy* in the [maas-ui](https://github.com/canonical-web-and-design/maas-ui/) repository. The [maas-ui](https://github.com/canonical-web-and-design/maas-ui/) repository uses yarn’s implementation of [monorepos](https://en.wikipedia.org/wiki/Monorepo), [yarn workspaces](https://yarnpkg.com/lang/en/docs/workspaces/), allowing us host multiple yarn projects within the same git repository with shared dependencies. A new react application was bootstrapped using [Create React App](https://github.com/facebook/create-react-app) in a project simply called *ui.* The new *ui* project is a React 16 app, built exclusively on the hooks API, [redux](https://redux.js.org/) (with [immer](https://github.com/immerjs/immer)) and [redux-sagas](https://redux-saga.js.org/). A third project, *shared*, contains components common to both *legacy* and *ui* (e.g. header, footer components). ### Development Proxying While routing between both *legacy* (AngularJS) and *ui* (React) apps is simply handled by Django in production, in development we needed a way to work on both projects seamlessly. We created a simple [proxying server](https://github.com/canonical-web-and-design/maas-ui/blob/master/proxy/index.js), using [ExpressJS](https://expressjs.com/) and [http-proxy-middleware](https://github.com/chimurai/http-proxy-middleware) to route requests between both the *legacy* and *ui* apps. The server also correctly proxies requests to the webpack devserver to support reloading for both projects, preserving the nice developer experience we would have for a single project. ## Into the Future From MAAS 2.7 onwards, new UI features in MAAS will be developed exclusively in React. We now have an excellent foundation on which to continue delivering UX and performance improvements to our MAAS users. If working on products like MAAS interests you, we’re [currently looking](https://boards.greenhouse.io/canonical) for UX Designers to join our team, and may be looking for frontend engineers in the near future. [Get in touch Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form) ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy). Sign up ## Share on --- ## Related posts [### MAAS installation: bare metal provisioning is easier than ever](https://canonical.com/blog/maas-installation-bare-metal-provisioning-is-easier-than-ever) MAAS brings cloud-like automation to physical servers. It helps teams discover, commission, deploy, and repurpose machines from a central control plane, turning bare metal into... [David Beamonte](https://canonical.com/blog/author/dbeamonte) 14 July 2026 [### Managing Ubuntu on bare metal at scale](https://canonical.com/blog/managing-ubuntu-on-bare-metal-at-scale) Modern infrastructure teams are expected to deliver cloud-like speed, consistency, and reliability, even when their workloads run on physical servers. Bare metal remains... [David Beamonte](https://canonical.com/blog/author/dbeamonte) 9 July 2026 [### Ubuntu Server: a platform made for enterprise scale](https://canonical.com/blog/ubuntu-server-a-platform-made-for-enterprise-scale) A platform is an environment that allows software to run smoothly across the infrastructure, runtime, and application layers. The key word there is “smoothly”: a good platform... [Rhys Knipe](https://canonical.com/blog/author/rhysknipe) 7 July 2026 [### VMware hypervisor deployment using MAAS](https://canonical.com/blog/vmware-hypervisor-deployment-using-maas) Most modern datacenters are inherently heterogeneous. VMware environments coexist with container platforms, databases, and other bare-metal workloads, often on the same... [David Beamonte](https://canonical.com/blog/author/dbeamonte) 28 May 2026