Over the past few years, each new Umbraco release has steadily improved the platform with better performance, support for newer .NET versions, and incremental feature updates. While these releases refined the CMS, its core development model remained largely unchanged.

Umbraco 14 is different.

This is the first release since the migration to .NET Core that fundamentally changes how developers build and extend the platform. Content editors will hardly notice the difference, but for developers maintaining custom dashboards, Property Editors, or packages, Umbraco 14 introduces an entirely new architecture.

Is the migration effort worth it?

In our opinion, absolutely. Although upgrading may require rewriting parts of your Backoffice extensions, the new architecture removes many of the limitations that have accumulated over the years and provides a much stronger foundation for future development.

First impressions of Umbraco 14

When launching Umbraco 14 for the first time, it’s easy to think that very little has changed.

The content tree, media section, document types, and editorial workflow all feel familiar. Existing Umbraco users will quickly find their way around the interface.

The real changes become apparent only when working with custom Backoffice extensions.

A dashboard developed several years ago, a custom Property Editor, or an internal administration section may suddenly stop working—not because of a bug, but because the technology behind them has been completely replaced.

This is where the true scale of Umbraco 14 becomes visible.

The end of AngularJS is more than a framework change

The most talked-about change in Umbraco 14 is undoubtedly the complete removal of AngularJS.

At first glance, this may seem like a simple frontend technology upgrade. In reality, it represents a complete redesign of the Backoffice development model.

For years, AngularJS served as the foundation of Umbraco’s Backoffice. Custom dashboards, Property Editors, and administration tools relied on Angular controllers, $scope, package.manifest, and several APIs tightly coupled to the CMS.

The problem was obvious.

AngularJS officially reached end-of-life years ago, making it increasingly difficult to maintain modern applications while depending on an outdated framework.

From a software development perspective, replacing AngularJS wasn’t optional—it was inevitable.

How the Backoffice changed in Umbraco 14

Source: CodeMasters – original illustration.

Why Web Components?

One of the most interesting architectural decisions in Umbraco 14 is the adoption of Web Components.

Instead of replacing AngularJS with another JavaScript framework, the Umbraco team chose web standards.

This decision significantly reduces framework dependency and makes custom extensions easier to maintain in the long term.

Whether your frontend team prefers React, Vue, Lit, or another technology, the underlying Backoffice architecture is no longer tied to a single framework.

For package developers, this means greater stability and a cleaner extension model that is much less likely to require major rewrites in future releases.

From our experience

In most migration projects, upgrading Umbraco itself isn’t the most time-consuming task.

The real effort lies in identifying every custom Backoffice component developed over the years.

Before starting a migration, it’s worth creating an inventory of:

• custom dashboards,
• Property Editors,
• administration sections,
• components using package.manifest.

This simple step makes project estimation far more accurate and reduces unpleasant surprises during the upgrade process.

Extension API replaces package.manifest

If there’s one feature that fundamentally changes everyday development in Umbraco 14, it’s the new Extension API.

Previous versions relied heavily on AngularJS and package.manifest files to register custom Backoffice components.

The new approach introduces manifests together with Web Components, resulting in a cleaner, more maintainable extension model.

Umbraco 13

angular.module("umbraco").controller(
    "CodeMasters.Dashboard",
    function ($scope) {
    }
);

Umbraco 14

export const manifests = [
  {
    type: "dashboard",
    alias: "CodeMasters.Dashboard",
    name: "CodeMasters Dashboard",
    element: () => import("./dashboard.js")
  }
];

The improvement isn’t just about writing less code.

The philosophy has changed.

Instead of building extensions around AngularJS, developers now work with standard browser technologies and modern JavaScript modules.

Evolution of the extension model

Source: CodeMasters – original illustration.

Management API brings consistency

Another major architectural improvement is the introduction of the Management API.

Older versions exposed multiple controllers and internal endpoints that evolved independently over time.

Umbraco 14 introduces a unified REST API that powers the Backoffice while also serving external integrations.

This provides a far more consistent foundation for enterprise projects integrating Umbraco with ERP, CRM, PIM, or custom business applications.

Another welcome addition is OpenAPI support, making API exploration and documentation considerably easier.

Although this change is largely invisible to content editors, it has a significant impact on developer productivity.

How communication works in Umbraco 14

Source: CodeMasters – original illustration.

What surprised us most

After spending some time with the new architecture, one thing quickly becomes clear.

The goal wasn’t simply to replace AngularJS.

Instead, Umbraco’s development team took the opportunity to simplify and standardize the entire extension model.

Custom Backoffice components now feel much closer to modern frontend development than to framework-specific CMS customization.

That’s a significant improvement for teams maintaining long-term enterprise solutions.

Our recommendation

If you’re starting a new Umbraco project today, choosing version 14 is the obvious decision.

The new architecture forms the foundation for future platform development, making Extension API and Management API the technologies worth investing in.

For existing projects, migration should be planned carefully.

Updating the backend is usually straightforward.

Migrating custom Backoffice extensions requires considerably more attention.

A proper technical audit before the upgrade can dramatically reduce both project risk and implementation time.

Final thoughts

For content editors, Umbraco 14 feels familiar.

For developers, it represents one of the biggest architectural shifts in the platform’s history.

The removal of AngularJS, the introduction of Extension API, and the new Management API establish a modern development model that aligns with current web standards and simplifies long-term maintenance.

Rather than thinking of Umbraco 14 as another CMS update, it’s more accurate to view it as a new foundation for future Umbraco projects.