Umbraco 18: What Is New, Should You Migrate?

Umbraco 18 is now available, but the migration decision is not a simple yes or no. As of 7 July 2026, Umbraco's GitHub releases list 18.0.1 as the latest Umbraco 18 patch, after 18.0.0 was released on 25 June 2026. Umbraco's support schedule lists version 18 as STS, with security phase beginning on 25 March 2027 and end-of-life on 25 June 2027.

That support window matters. If you are building a new project and your required packages already support Umbraco 18, it is worth testing now. If your production site is already stable on Umbraco 17 LTS, the safer business answer is usually to evaluate 18 in staging, but stay on 17 LTS unless 18 unlocks a specific feature, package, API, or implementation benefit you actually need.

This article focuses on the practical question: what is new in Umbraco 18, what risks should you check, and when should an Australian business migrate? For broader upgrade planning, see our Umbraco 17 LTS migration checklist and Umbraco development services.

What Is New in Umbraco 18?

The Umbraco 18.0.0 release overview lists 176 bug fixes and feature additions, including four notable features and 36 breaking changes. The important theme is not one single marketing feature. It is a mix of platform cleanup, Global Elements work, Delivery API and OpenAPI changes, UI Library changes, backoffice polish, and developer-facing changes that affect custom implementations.

Area	What changed	Why it matters
Global Elements	The release notes call out Global Elements as a notable feature, plus related element repository, cache, tree, search, tags, and UX work.	Sites with reusable structured content should review how this changes modelling, permissions, editorial workflow, search, and API assumptions.
Delivery API and OpenAPI	Umbraco 18 includes typed OpenAPI schemas per content type, OpenAPI generation changes, custom backoffice OpenAPI registration work, and Delivery API response changes.	Teams using generated clients, API contracts, headless delivery, integrations, or custom backoffice APIs need regression tests, not just a CMS smoke test.
Backoffice UI and UX	The release overview groups 20 UI and UX updates, including v18 UI adjustments, login and localisation improvements, global search work, save/publish waiting states, and element picker fixes.	Editors may see smoother workflows, but custom dashboards, property editors, and backoffice packages need compatibility checks.
Performance and editor experience	A notable performance change fixes a bottleneck when a Tiptap editor appears on a document. Several UX fixes also apply to save, publish, validation, and workspace behaviour.	Large editor-heavy sites should benchmark documents with real block, rich text, media, and multilingual content before and after upgrade.
Developer experience	The release notes include RecurringBackgroundJobBase API refinement and a shift from Swashbuckle.AspNetCore to Microsoft.AspNetCore.OpenApi for OpenAPI document generation.	Custom scheduled jobs, API documentation, package code, and integration tests may need updates.
Patch fixes after 18.0.0	Umbraco 18.0.1 includes bug fixes for navigation sort order, document URL persistence, HybridCache behaviour, relations, and OpenAPI document registration.	If you do test 18, test on the latest 18.0.x patch rather than the initial 18.0.0 release.

The Case for Migrating to Umbraco 18

Move to Umbraco 18 when the business case is clear. A new build can choose 18 if the package ecosystem is ready and the team wants to start on the latest major line. A rebuild can also be a sensible moment to target 18 because you are already testing content models, APIs, deployment, integrations, and editor workflows from the ground up.

Existing sites may have a stronger reason to move if they need the Umbraco 18 platform changes directly. Global Elements and related element handling may matter for reusable content architecture. Delivery API and OpenAPI improvements may matter for headless or integration-heavy builds. UI and backoffice changes may matter where editors spend serious time in the CMS. Developer changes may matter where custom APIs, package development, or background jobs are part of the site.

The migration case is strongest when three things are true: the feature benefit is specific, the compatibility checks are clean, and the team has enough time to test the real site rather than a clean install.

The Case for Waiting

Do not migrate just because 18 exists. Umbraco's lifecycle page lists Umbraco 18 as STS, with end-of-life on 25 June 2027. It lists Umbraco 17 as LTS, with end-of-life on 27 November 2028. For a production website where stability and long support are the main goals, that difference is not a footnote. It is the centre of the decision.

Waiting is the better move when your site is already stable on Umbraco 17 LTS, key packages have not confirmed 18 support, editors are in a busy trading period, the team cannot run proper staging QA, or the migration would compete with higher-value work. It is also reasonable to wait for more 18.x patch maturity if your implementation is complex.

For many businesses, the right plan is to keep production on Umbraco 17 LTS, create a staging branch for Umbraco 18, document blockers, and revisit the decision once package and implementation readiness are proven.

Decision Matrix

Situation	Recommendation	Reason
New Umbraco project starting now	Consider Umbraco 18 after package checks	You avoid migrating later, but STS timing and ecosystem readiness still need review.
Stable Umbraco 17 LTS site	Usually stay on 17 LTS for production	17 has the longer support runway and lower immediate migration pressure.
Umbraco 17 site needing an 18-specific feature	Run an Umbraco 18 staging spike	A feature-led migration can be justified, but only after compatibility testing.
Older Umbraco version with technical debt	Do discovery before choosing the target	The right answer may be staged upgrade, 17 LTS, 18, rebuild, or content migration.
Heavily customised backoffice	Wait until extension testing is complete	Umbraco 18 includes breaking changes and UI Library work that can affect custom interfaces.
Headless or integration-heavy site	Test API contracts first	Delivery API and OpenAPI changes can affect clients, schema assumptions, and deployment checks.

A Practical Migration Plan

1. Record your current state. Note the Umbraco version, runtime, hosting, packages, custom code, APIs, editor workflows, content volume, integrations, forms, search, and analytics setup.
2. Decide why 18 matters. Name the feature, support, architecture, or project reason. If there is no clear reason, treat 18 as a research branch rather than a production target.
3. Check package support. Confirm every NuGet and backoffice package supports Umbraco 18, including paid products and agency-built components.
4. Upgrade a staging copy. Use real content, media, redirects, forms, members, permissions, and integrations. A clean install proves very little.
5. Run editor QA. Ask editors to create pages, manage reusable content, edit blocks, publish, rollback, use search, upload media, switch cultures, and complete approval workflows.
6. Run technical regression tests. Test APIs, OpenAPI clients, background jobs, custom controllers, authentication, distributed cache, deployment, logs, and rollback.
7. Protect SEO and analytics. Crawl before and after, compare URLs, validate redirects, metadata, canonicals, schema, sitemaps, forms, analytics, and conversion events.
8. Choose go, wait, or stay on LTS. Make the decision from evidence, not version excitement.

Final Recommendation

For most existing business websites, the answer is: test Umbraco 18, but do not rush production migration. Umbraco 18 is worth serious evaluation, especially for new builds, rebuilds, Global Elements work, API-heavy projects, and teams that need the latest major line. But Umbraco 17 LTS remains the more conservative production choice when long support, stability, and package maturity are the priority.

If you are on an older Umbraco version, the first step is not choosing 17 or 18. The first step is a migration discovery: current version, custom code, packages, content model, hosting, SEO risk, and business goals. Once that evidence is clear, the target version usually becomes obvious.

Sources Checked

• Umbraco CMS GitHub releases
• Umbraco CMS 18.0.0 GitHub release notes
• Umbraco CMS 18.0.1 GitHub release notes
• Umbraco CMS 18.0.0 release overview
• Umbraco long-term support and end-of-life schedule
• Umbraco upgrade documentation
• Umbraco version-specific upgrade notes