Umbraco 14 was one of the most important releases in the platform’s history. The completely rebuilt Backoffice, the move away from AngularJS, and the new Extension API changed the way custom extensions were developed and laid the foundation for future versions of the CMS.

Umbraco 16 does not attempt to redefine that architecture again. Instead of another revolution, it refines the mechanisms introduced earlier and adds a set of features that have a real impact on the day-to-day work of both developers and content editors.

At first glance, the list of changes may seem less spectacular than in Umbraco 14. In practice, however, version 16 shows that the new Backoffice has reached a level of maturity suitable for building and maintaining even complex production projects.

If you are planning a new project or considering a migration from Umbraco 14 or 15, it is worth taking a closer look at the changes introduced in this release.

Tiptap replaces TinyMCE

One of the most visible changes in Umbraco 16 is the replacement of TinyMCE with the modern Tiptap editor.

At first glance, this may seem like a simple replacement of the component responsible for editing rich text. In practice, the change goes much further.

TinyMCE has been part of Umbraco for many years. It was stable and familiar to most developers, but over time it became increasingly difficult to evolve it in line with modern web application standards.

Tiptap is built on top of ProseMirror, which gives it greater flexibility, better extensibility, and a more modern architecture.

For content editors, this means a smoother and more flexible editing experience.

For developers, it means new opportunities to extend and customize the editor in a way that is consistent with the new Backoffice architecture.

What does this mean in practice?

JeIf your project uses only the default Rich Text Editor configuration, the migration should be relatively straightforward.

More attention will be required in projects that use:

• custom TinyMCE configuration,
• custom plugins,
• custom toolbar buttons,
• integrations with external JavaScript libraries.

This is also a good opportunity to review existing customizations and decide whether they are still necessary. In many cases, the new editor provides capabilities that previously required custom extensions.

Source: CodeMasters – original illustration.

From our experience

Changing the text editor may sound like a small detail, but from our perspective it is one of the most important changes in Umbraco 16.

In long-running projects, TinyMCE configuration often grew into hundreds of lines of code. Moving to Tiptap is a good opportunity to simplify that setup and remove legacy extensions that are no longer needed.

Lock & Hide Properties – more control over editing

Another useful addition is Lock & Hide Properties.

Previously, all fields in an editing form were generally visible to every user with access to the document.

In larger projects, this often resulted in editors seeing dozens of properties even though they only needed to work with a small subset of them.

Umbraco 16 allows you to:

• hide selected properties,
• prevent selected fields from being edited,
• adapt the editing experience to the user’s role.

Although this feature is primarily aimed at administrators and editors, its impact on project quality is much broader.

A well-designed editing form means fewer mistakes, faster onboarding for new editors, and greater consistency in published content.

Example use cases

This feature is particularly useful in projects where:

• the marketing team manages page content,
• the SEO team manages metadata,
• administrators handle technical configuration.

Each group can work with an interface tailored to its responsibilities without having to create separate document types.

Source: CodeMasters – original illustration.

Extension API continues to mature

Umbraco 14 introduced a completely new model for extending the Backoffice.

Version 16 does not replace that model. Instead, it continues to expand it.

More official extension points are available, which means developers increasingly avoid undocumented workarounds or direct interaction with internal Backoffice components.

From our perspective, this is one of the strongest aspects of the current direction of Umbraco.

Rather than adding new exceptions, the platform is becoming more predictable and consistent, which matters a lot in projects maintained over several years.

A simple manifest may look like this:

import type { UmbExtensionManifest } from "@umbraco-cms/backoffice/extension-api";

const manifest: UmbExtensionManifest = {
  type: "dashboard",
  alias: "CodeMasters.Dashboard",
  name: "CodeMasters Dashboard",
  element: () => import("./dashboard.element.js")
};

export const manifests = [manifest];

The dynamic import is worth noting. It allows the extension code to be loaded only when needed instead of including everything in the initial Backoffice bundle.

From our experience

W In Umbraco 13, custom extensions often followed patterns specific to a given project.

With versions 14–16, it is worth reversing that approach:

1. First, check whether an official extension type already exists.
2. Then use the available Backoffice contexts and repositories.
3. Only after that introduce your own abstraction layer.

This reduces the number of moving parts that may break during future upgrades.

Management API – consistent communication with the Backoffice

Umbraco 16 continues to evolve the Management API, which has become the primary way to communicate with the Backoffice.

The change is not only about naming. It is about clearly separating the administrative interface from application logic. The Backoffice becomes an API client, just like any other application using the system’s services.

For projects integrated with ERP, CRM, PIM, or other external tools, this means a more predictable architecture. Instead of building around a random collection of custom controllers, you can apply consistent rules for versioning, authorization, and documentation.

A custom Backoffice controller may look like this:

using Microsoft.AspNetCore.Mvc;
using Umbraco.Cms.Api.Management.Controllers;

[ApiController]
[Route("umbraco/management/api/v1/orders")]
public class OrdersController : ManagementApiControllerBase
{
    [HttpGet]
    public IActionResult GetOrders()
    {
        return Ok(new[]
        {
            new { Id = 101, Status = "Processing" },
            new { Id = 102, Status = "Completed" }
        });
    }
}

This example is intentionally simple. In a real project, the controller should delegate business logic to the application layer instead of implementing it directly.

From our experience

If a project still uses endpoints created several versions ago purely for Backoffice purposes, moving to Umbraco 16 is a good time to review them.

Not every controller needs to be rewritten immediately. However, it is worth checking whether:

• authorization follows the current Backoffice model,
• endpoints have clearly defined versions,
• API contracts are documented,
• business logic is not placed directly inside controllers.

In many cases, such a review provides more value than simply increasing the package version.

Source: CodeMasters – original illustration.

.NET 9 – a newer platform foundation

UmbracUmbraco 16 is built on .NET 9.

From a day-to-day development perspective, this does not change the way content is modeled or how Razor views are built. It does, however, require a review of the entire project environment:

• NuGet packages,
• integration libraries,
• custom extensions,
• CI/CD pipelines,
• container base images,
• hosting environments.

A basic project configuration looks familiar:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Umbraco.Cms" Version="16.0.0" />
  </ItemGroup>
</Project>

In practice, dependencies that are not yet compatible with the new Umbraco version may cause more problems than the TargetFramework change itself.

For that reason, it is usually better to begin the upgrade by checking package compatibility rather than simply changing the version number in the project file.

Accessibility and Backoffice refinement

Some of the improvements in Umbraco 16 do not make headline release notes, but they matter in daily use.

The new Backoffice is developed as an extension-based system where even standard UI elements are registered and managed through the extension model.

This helps improve consistency across the interface and makes it possible to refine areas such as:

• keyboard navigation,
• focus states,
• validation messages,
• component behavior,
• consistency between custom extensions and native Backoffice sections.

These are not features that look impressive in a list of changes, but they matter in systems used every day by larger editorial teams.

Migration from Umbraco 14 or 15 to 16

Migrating from version 14 or 15 is much closer to a regular platform upgrade than the architectural transition required when moving from Umbraco 13.

The foundation remains the same:

• the new Backoffice,
• Web Components,
• Extension API,
• Management API,
• TypeScript.

That does not mean the upgrade can be done without preparation.

The following areas deserve the most attention.

Rich Text Editor

Projects with custom TinyMCE configuration should be reviewed before the upgrade.

Tiptap has a different architecture and extension model, so TinyMCE configuration should not be migrated mechanically.

Packages and extensions

Every package should have a version compatible with Umbraco 16.

This is especially important for packages that modify the Backoffice or provide custom Property Editors.

Integrations

Custom endpoints, DTOs, and authorization mechanisms should be tested independently from the CMS itself.ne endpointy, modele DTO i mechanizmy autoryzacji warto przetestować niezależnie od samego CMS-a.

Runtime environment

Hosting, containers, and pipelines must support .NET 9.

Minimal migration checklist

• back up the database and wwwroot,
• inventory NuGet packages and frontend extensions,
• review all Data Types using the Rich Text Editor,
• test custom Backoffice endpoints,
• build the project with compiler warnings enabled,
• migrate first on a copy or staging environment,
• run editorial tests, not only frontend tests.

Is it worth migrating to Umbraco 16?

The answer depends on the version your project currently uses and how long you plan to maintain it.

For new projects, Umbraco 16 offers a mature Backoffice, an up-to-date .NET stack, and an extension model that no longer requires investment in technologies that have already been retired.

For projects running on versions 14 or 15, upgrading is a logical step, especially when:

• the project will continue to be actively developed,
• the team wants to use Tiptap,
• newer Extension API capabilities are needed,
• additional integrations are planned,
• current packages provide support for version 16.

A stable project that is no longer being actively developed may require a different decision. In that case, the choice should be based on maintenance costs, security support, and the expected application lifecycle.alizacji bezpieczeństwa i planowanym cyklu życia aplikacji.

Our recommendation

Umbraco 16 is not another revolution. That is exactly what makes it interesting.

Version 14 changed the foundation of the Backoffice. Version 16 shows that the new architecture is no longer experimental or transitional.

Extensions now follow an official model, the Management API provides a consistent communication layer, and Tiptap modernizes one of the most frequently used parts of the administration interface.

For new projects, it makes sense to:

• build extensions on the Extension API,
• treat the Management API as the default choice for Backoffice-related functionality,
• avoid dependencies on undocumented internal components,
• design editing forms around the actual role of the editor,
• rebuild Tiptap configuration intentionally instead of copying old TinyMCE settings.
  

This requires some upfront learning, but it reduces the cost of future upgrades.

Summary

Umbraco 16 develops the direction established by version 14 instead of rebuilding the platform again.

The most important changes are:

• Tiptap as the new Rich Text Editor,
• better control over editorial forms,
• continued development of the Extension API,
• broader use of the Management API,
• migration to .NET 9,
• further refinement of the new Backoffice.

None of these changes individually has the scale of removing AngularJS. Together, however, they make the platform more mature and predictable in everyday development.

For developers, the key conclusion is simple: the architecture introduced in Umbraco 14 remains relevant. Knowledge gained while building extensions for the new Backoffice continues to pay off in subsequent versions of the platform.