Migrating from Umbraco to Payload: a 2026 guide for teams off the upgrade treadmill

If you run Umbraco 13, mark 14 December 2026 on your calendar: that is when it reaches the end of its long-term support (LTS). The .NET runtime underneath it loses Microsoft support earlier, on 10 November. Umbraco 8 already passed its end of life in February 2025. The pattern is the point: with Umbraco, there is always a next upgrade, and missing it eventually means running a CMS that no longer gets security fixes.

Most articles about this will tell you to upgrade. Umbraco 17, released 27 November 2025, is the current LTS and runs to 27 November 2028; Umbraco 18, released 25 June 2026, is the latest release and an STS running to 25 June 2027, with Umbraco 19, another STS, scheduled for 10 December 2026. Upgrading is a reasonable move and for plenty of teams the right one. This guide covers two other paths: buying time with Umbraco’s paid extended support (XLTS), and rebuilding on Payload, a CMS you write in code and run as part of your own application. It makes the case for the second.

We should be upfront about one thing before going further, because it changes the whole argument - Umbraco is free. The core CMS is open source under an MIT license, and there is no platform fee to escape. That makes this a different conversation from leaving a commercially licensed system, and it means the reasons to move have to be good ones. We are an official Payload partner, so our bias is on the table. We will also be clear about when staying on Umbraco is the smarter call.

Why teams leave Umbraco even though it is free

The Umbraco core costs nothing, so the case for moving is a maintenance question: how much work the platform asks of your team over the years you keep it running.

Umbraco releases a new major version twice a year, and each major release introduces breaking changes. Every fourth one is an LTS release, which Umbraco supports for far longer so teams can skip the twice-a-year upgrades and move on a slower cycle. If you track the latest releases, you are absorbing breaking changes on a roughly six-month cadence. If you pin to an LTS version instead, you trade frequency for a cliff: support runs 24 months, security fixes run another 12, and then a forced migration to the next LTS lands on you. Either way, the upgrade work never really ends; it just moves to the next deadline.

A second cost sits alongside that one. A major Umbraco upgrade is not always a .NET upgrade. Umbraco tracks Microsoft’s November cadence, so the runtime changes roughly every other major. Umbraco’s upgrade documentation publishes the pairing: Umbraco 13 and 14 run on .NET 8, 15 and 16 on .NET 9, and 17 and 18 on .NET 10. Check your own target release against that table before planning the work.

Where the runtime does move, an LTS-to-LTS jump from 13 on .NET 8 to 17 on .NET 10 is a runtime upgrade as much as a CMS one, and it waits on any third-party package that has to catch up first. Teams running several Umbraco sites, each customized differently, feel this most, because every site is its own upgrade project.

The runtime also has its own clock. Microsoft support for .NET 8 ends on 10 November 2026, 34 days before Umbraco 13’s 14 December 2026 end of life, so a 13 estate loses its supported runtime before it loses its supported CMS. .NET 9 support ends the same day; Umbraco 15 and 16, which run on it, already reached their own end of life on 14 November 2025 and 12 June 2026.

Umbraco 14 in 2024 showed how deep a major’s breaking changes can run. It replaced the long-standing AngularJS back office with a new one built on web components and Lit (a lightweight library for building web components), which meant any custom property editor had to be rebuilt to keep working. That is a useful gauge of the platform’s upgrade cost: a single major version can oblige you to rewrite working code just to stand still.

None of this makes Umbraco a bad CMS. It is a mature, capable platform with a strong community. What you are really weighing is the maintenance tax that comes with it against running your content infrastructure on a stack your team already uses everywhere else.

Where the Umbraco costs actually are

Saying Umbraco is free needs a footnote, because most production Umbraco sites are not running on the free core alone.

The hosting and tooling around it carry subscription costs. Umbraco Cloud, the managed platform that handles hosting and automated upgrades, starts at €45 per month on Starter, which covers one Live environment; a development environment adds €45 per month. Standard is €280 per month, with a staging environment €70 per month on top, and Professional is €730 with staging included. Umbraco Heartcore, the headless software-as-a-service option, starts at €60 per month (Starter), with Standard at €300 and Professional at €1,100. Common add-ons like Umbraco Forms and Umbraco Deploy are licensed separately. Umbraco also raised its prices on January 1, 2026, which is the kind of recurring increase that makes any managed platform more expensive to stay on each year.

The larger cost is harder to see on an invoice. It is the engineering time your team spends on upgrades whose main job is keeping you supported rather than shipping features your users asked for. New majors do add real capabilities, but a lot of the work each cycle goes into staying current rather than building anything new. A team doing two Umbraco majors a year, or a heavy LTS-to-LTS jump every couple of years, is spending developer weeks staying in place. That is the number worth comparing against the cost of moving once.

What Payload is, and how its upgrades differ

Payload is an open-source CMS and application framework built on Next.js and TypeScript. A few of its properties matter most to a team considering a move from Umbraco.

The biggest difference is the model. In Payload you define your collections, fields, and access control in TypeScript, in your repository, under version control. The schema is code, so it goes through pull requests, code review, and your normal deploy pipeline. There is no separate back-office configuration that can drift away from what the codebase says.

Then there is where it runs. Since version 3.0, released in November 2024, Payload installs directly into a Next.js application, which means your CMS and your front end live in a single project and ship in one deploy. Payload also exposes a Local API, so server-side code reads from the database directly without an HTTP round trip. For a content site, that collapses the usual gap between a headless backend and a separate frontend into one codebase.

Licensing is the last piece. Payload is MIT-licensed and free to self-host, so you pay for your own infrastructure and own everything that gets built. On the stability question that matters when you leave one open-source project for another, Payload was acquired by Figma in June 2025 and remains open source and actively developed, with a large company now behind it.

Payload is not free of upgrade work either. It is a younger platform, and its own major versions, such as the move from 2 to 3, have involved meaningful changes. A minor Payload upgrade is a package update plus any database migrations, which you run and review like any other code change. Since 3.0, Payload also declares which Next.js versions it supports, so a Payload upgrade can move your Next.js version, and a Next.js upgrade can wait on Payload.

Umbraco 13, Umbraco 17, Heartcore and Payload compared

Umbraco CMS and Umbraco Heartcore are separate products, so they get separate columns. Heartcore is Umbraco’s hosted headless service; the CMS is the self-hostable platform.

	Umbraco 13 (LTS)	Umbraco 17 (LTS)	Umbraco Heartcore	Payload
License	Free, MIT (core)	Free, MIT (core)	Paid SaaS subscription	Free, MIT (core); SSO, publishing workflows and audit logs are enterprise-licensed, no published price
Hosting	Self-host or Umbraco Cloud	Self-host or Umbraco Cloud	Umbraco-hosted only	Self-host (any Node host)
Runtime	.NET 8	.NET 10	Managed by Umbraco	Node, TypeScript
Content model	Document types in back office	Document types in back office	Document types in back office	Collections defined in code
Headless	Content Delivery API	Content Delivery API	Native headless	Native, API-first
Front end	Razor or headless front end	Razor or headless front end	Headless only	Next.js (React)
Upgrade shape	Major upgrade; runtime moves every other major	Major upgrade; runtime moves every other major	Managed by Umbraco	Package update plus migrations you run; majors carry breaking changes
Support ends	14 December 2026	27 November 2028	While subscribed	No published support schedule
Extended support	XLTS available, paid	XLTS available after EOL, paid	Not applicable	No published offer

The row that usually settles the decision is the upgrade shape, since that is the work your team repeats for as long as you stay. Payload’s column carries its own work: you run its database migrations, you own the hosting, and you carry the operational responsibility a managed platform would otherwise absorb.

Version and support facts in this table were verified against Umbraco’s long-term support and end-of-life schedule, Umbraco’s XLTS policy, Microsoft’s .NET support policy and Payload’s enterprise features on 11 September 2026.

Deciding between upgrading, XLTS and replatforming

Three paths lead out of an Umbraco 13 estate, and each is defensible under different conditions.

Upgrade to Umbraco 17 LTS. Keeps you on Umbraco with support to 27 November 2028; Microsoft support for .NET 10 ends on 14 November 2028, 13 days earlier. The work is an LTS-to-LTS jump from .NET 8 to .NET 10 across three intermediate majors, each with breaking changes listed in Umbraco’s breaking changes overview. Umbraco 14 replaced the AngularJS back office with web components, so any custom property editor written for the old back office is rebuilt whether or not you were planning to touch it; the same release removed Nested Content, Grid Layout and macros. Umbraco 15 changed the data format of every block editor, which on a site with heavy block-editor use can mean a long-running content migration during which the site cannot serve requests. Umbraco 16 dropped TinyMCE from the core and migrates rich text data types that use it to TipTap. Umbraco’s own guidance for 13 also lists rebuilding fresh on 17 or later as an option. The conditions that favour staying are set out in Reasons to stay on Umbraco.

Buy XLTS. Umbraco sells Extended Long-term Support for LTS versions from Umbraco 10 onward, in blocks of 6, 12 or 24 months, beginning the day after end of life. Umbraco sets out the terms: security patches only, a frozen feature set, and extensions that must run continuously with no gaps. XLTS does not extend support for anything outside Umbraco, so a .NET runtime past its own Microsoft date stays past it, and third-party packages remain their vendors’ responsibility. Umbraco’s XLTS pages do not say whether its paid add-ons, such as Forms or Deploy, are included, so confirm this for each add-on you run. And while Umbraco positions XLTS as covering regulatory and contractual obligations, a paid patch stream is not in itself a compliance guarantee; if you have an obligation to evidence, check the subscription against that obligation before relying on it.

Replatform. Justified when the reasons to leave reach past this one deadline, which the rest of this guide covers.

A worked example

The following is illustrative. It is not a client project and no outcome is claimed for it.

A university runs Umbraco 13 with roughly 4,000 pages, a publishing team of six across three faculties, three custom property editors written for the old AngularJS back office, two paid add-ons, and one .NET 8 integration with a student records system. Its procurement cycle takes about nine months from business case to signed contract.

Work the dates first. Microsoft support for .NET 8 ends 10 November 2026 and Umbraco 13 ends 14 December 2026. If the platform decision starts in September 2026, a nine-month procurement lands after both. The CMS therefore needs cover past 14 December 2026 while the decision is made.

The CMS coverage calculation points to XLTS for 24 months, with discovery run inside that window, conditional on the university accepting the separate runtime risk below. Coverage starts the day after end of life, on 15 December 2026, so 24 months of it runs to 14 December 2028. Nine months of procurement puts the signed contract in June 2027, and the three-to-twelve-month delivery range in this guide puts cutover between September 2027 and June 2028. A 12-month block would end on 14 December 2027 and cover only the short end of that range; 24 months covers all of it, with about six months to spare. Twelve months works for a longer delivery only if the university plans the extension now and buys it before 14 December 2027, because Umbraco requires extensions to run continuously with no gaps.

The runtime gets no such cover. Umbraco’s version table pairs 13 with .NET 8 and nothing else, so no supported runtime upgrade exists while the CMS stays on 13, and XLTS is a subscription for the CMS. After 10 November 2026 until cutover, the site runs on a .NET 8 that Microsoft no longer patches. That gap needs a named risk owner and an explicit assessment of whether compensating controls are sufficient; those controls do not restore runtime support. If that exposure is unacceptable, XLTS alone cannot make this plan viable: the university must shorten procurement and bring forward an upgrade or cutover to a supported stack.

The three property editors are what discovery has to price. They must be rebuilt for the new back office to upgrade, and they must be rebuilt as Payload fields to replatform. Their cost is not avoided by either path.

What to check first, and what would change that answer

Start with the upgrade work the documentation already describes. Umbraco 14 removed Nested Content, Grid Layout and macros, and 16 dropped TinyMCE from the core. Count how many of each this site uses, along with any custom TinyMCE configuration the editors depend on. Then measure the volume of block-editor content, because Umbraco 15 converts the stored format of every block editor and, by default, the site cannot serve requests while the conversion runs. Those counts price the upgrade path, and they are the first thing discovery should produce. The breaking-changes overview and the Umbraco 15 content-migration page are both in Sources. For the replatform path, discovery produces the matching counts: the Razor templates to rebuild as React components, the pages and media to migrate, the URLs that need redirects, and the work to replace the two paid add-ons and rebuild the student records integration for the new stack.

If the three property editors can be replaced by stock Umbraco fields, their cost leaves both paths. The upgrade no longer has to rebuild them for the new back office, and a Payload build no longer has to reproduce them as custom fields, so the decision turns on the rest of the estate.

Confirm that XLTS covers the two paid add-ons. Umbraco’s XLTS pages say nothing about Forms, Deploy or any other licensed add-on, so ask before the block is bought. An add-on left outside the subscription needs its own plan for the same period.

If the student records integration is already scheduled for replacement, replatforming stops carrying its largest technical risk and the balance shifts toward replatforming.

If procurement can be shortened — an existing framework agreement, a call-off contract, a supplier already on a preferred list — the whole XLTS step may be unnecessary, and the XLTS budget can go to the upgrade or rebuild instead.

The migration, stage by stage

A move to Payload divides into five stages, and how cleanly the first one goes shapes everything after it.

Start with an audit

Catalogue the site before a single record moves. List every document type and its properties, every template and Razor view, every package and add-on (Umbraco Forms, Deploy, and whatever community packages have accumulated), the member and login setup, and the media library. Packages are the usual source of surprises, because each one represents behaviour you will replace, rebuild, or retire, and you would much rather learn that now than at cutover.

The audit is also when you decide what to keep. A long-lived Umbraco install tends to collect document types that have drifted out of shape, and rebuilding gives you a clean chance to fix them instead of carrying the mess across.

Model the content as Payload collections

Umbraco keeps your content in document types, each a set of properties edited through the back office. Payload keeps it in collections, where every collection is a single TypeScript config that declares its fields, relationships, and access rules in one place.

A typical Umbraco page document type maps to a Payload collection along these lines:

import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: { useAsTitle: 'heading' },
  access: { read: () => true },
  fields: [
    { name: 'heading', type: 'text', required: true },
    { name: 'path', type: 'text', required: true, unique: true },
    { name: 'summary', type: 'textarea' },
    { name: 'hero', type: 'upload', relationTo: 'media' },
    { name: 'sections', type: 'blocks', blocks: [/* your content blocks */] },
  ],
}

Everything that collection needs lives in that one file. Payload reads it to build the database tables, the editing screens, and the typed API, and because it sits in your repository it goes through review and deploys with the rest of the app.

Flat fields like a heading or a path are the easy part. The effort concentrates on Umbraco’s richer property editors. Block grid and nested content become Payload’s blocks field, multinode tree pickers become relationship fields, and culture variants on a multilingual site map onto Payload’s localization. Members carry across as well, because authentication is a built-in collection type in Payload, so Umbraco logins land in a real auth collection rather than something bolted on the side. Scope the mapping work around those editors, since that is where the hours go.

Move the content and media

Once the collections exist, a migration script reads from Umbraco and writes through Payload’s Local API. Umbraco can hand you content through its Content Delivery API or straight from the database; you reshape each record and create it in Payload. The loop itself stays small:

import payload from 'payload'

for (const node of umbracoNodes) {
  await payload.create({
    collection: 'pages',
    data: {
      heading: node.name,
      path: node.urlSegment,
      summary: node.properties.summary,
      sections: toBlocks(node.properties.bodyText),
    },
  })
}

Media moves to whichever storage adapter you choose, from S3 to Vercel Blob, and the script fixes up references as it writes. Running the import through Payload’s API rather than raw SQL means every record passes through validation and hooks, so broken legacy data shows up during the run instead of in production.

Rebuild the front end

Payload runs on Next.js, so the front end becomes a React application pulling content from the Local API. Umbraco’s Razor templates and views have no direct equivalent and get rebuilt as React components. A team already working in React will find this familiar, and on most projects it is the single biggest piece of the job. For a content site with a settled set of templates it is also predictable, which makes it easy to scope.

Redirects, SEO, and sign-off

Getting content into Payload is only half the launch. Every old Umbraco URL needs a 301 redirect to its new path so the rankings you have earned survive the move, and metadata, canonical tags, sitemaps, and structured data all have to come across with it. Then walk the old site against the new one page by page, checking content parity, redirects, forms, integrations, and Core Web Vitals. This is the work that protects your existing traffic, so it earns proper time rather than a rushed final day.

Timelines and the real cost picture

What sets the timeline is the complexity of the site, not the platform you move to. A clean, content-led site usually lands in three to six months; a large one carrying heavy customization and many integrations runs nearer six to twelve. Read those as ballpark figures rather than quotes. A team that does this regularly often beats them, which is what the Ingersoll Rand build later in this section shows.

Cost works differently here than it would for a licensed system. There is no CMS license to cancel, because Umbraco never charged one. What drops off your bill is the recurring spend on Umbraco Cloud or Heartcore and any paid add-ons, together with the engineering hours that currently go into staying supported. Moving to Payload is an up-front cost, and after it you are paying for infrastructure you already understand, a database, file storage, and Node hosting, plus the work of keeping Payload and Next.js current.

Give yourself room to do it well. A year to eighteen months ahead of an end-of-life date is roughly what it takes to run discovery, settle the platform question, move the content, and keep your search rankings intact without forcing the cutover. Umbraco 13’s 14 December 2026 date is now too close for most estates to finish a move before it, which is the situation XLTS, covered above, is sold for.

Not every cost falls on the engineering side. Your editors have spent years inside the Umbraco back office, and Payload’s admin, clean and configurable as it is, will feel unfamiliar at first. Plan for some training, and expect publishing to run a little slower for a week or two after launch while the team settles in.

A deadline-driven CMS replacement is familiar ground for us. Ingersoll Rand’s China sites were still on Oracle Content Manager when Oracle moved to discontinue it, with a hard switch-off date and no slack in the schedule. We delivered a new Payload platform in five months, carrying thousands of pages and tens of thousands of media assets and redirects across more than 20 brand tenants, and kept the live platform running throughout. The Ingersoll Rand case study covers it in full. An Umbraco end-of-life date creates exactly the same kind of fixed deadline.

Reasons to stay on Umbraco

Payload is the wrong choice for some teams, and it helps to be concrete about which.

Team fit matters most. If your engineers are most productive in C# and Razor, and .NET hiring is easy for you, switching to a TypeScript platform trades a comfortable, well-staffed team for a benefit they may not rate highly enough to justify the disruption.

Upgrade discipline matters too. The treadmill only hurts if it actually costs you, and a team that holds to Umbraco’s LTS track, keeps its packages current, and treats upgrades as routine maintenance is not losing meaningful time. For them, Umbraco 17 on .NET 10 is a solid, supported home with a clear path to the next LTS.

Then there is how much you depend on the wider Umbraco toolset. Leaning on Umbraco Cloud’s managed upgrades, on Umbraco Forms, or on a stack of community packages that would each need a replacement all raise the cost of leaving. Those are real dependencies, not details to wave away.

In the end it is a question of ownership and maintenance. If you are comfortable on .NET and disciplined about staying current, Umbraco remains a strong choice and there is no need to move. If you would rather write your content model in code, run your CMS and front end as one Next.js application, and review any database migrations an upgrade needs in your own repository like any other code change, that is the case for Payload, and it is the work we do.

How WAYF can help

As an official Payload partner and Top Contributor, WAYF has been shipping Payload and Next.js platforms for Fortune 500 companies, public institutions, and fast-growing teams. A good share of that work is migration. We have moved sites off Oracle Content Manager, WordPress VIP, and Wagtail, and an Umbraco end-of-life date sets up the same kind of project. We run it end to end, from auditing the instance and modeling the content through to the Next.js front end and an SEO-safe cutover.

Weighing an Umbraco 17 upgrade against a move to Payload, we will look at your actual instance and tell you which path fits, staying on Umbraco included.

Book a call and we will give you a straight answer on whether Payload is the right move for your site.

FAQ

1. When does Umbraco 13 reach end of life?

   Umbraco 13 is an LTS release, built on .NET 8, and reaches end of life on 14 December 2026. Umbraco 17, released 27 November 2025, is the current LTS and runs until 27 November 2028; Umbraco 18 is the latest release, an STS running to 25 June 2027, and Umbraco 19, also an STS, is scheduled for 10 December 2026. A 13 estate has two dates to track: Microsoft support for .NET 8 ends on 10 November 2026, 34 days before the CMS date. Verified against Umbraco's support schedule and Microsoft's .NET support policy on 11 September 2026.

2. Is Umbraco free and open source?

   Yes. The Umbraco core CMS is open source under the MIT license and free to use. Costs come from optional products around it, such as Umbraco Cloud hosting, Umbraco Heartcore, and paid add-ons like Umbraco Forms.

3. Why migrate from Umbraco if it is already open source?

   Not to save on a license, since there is not one. Teams move to get off Umbraco's upgrade cycle, which ships breaking changes twice a year and carries a .NET runtime change on roughly every other major, and to consolidate onto a single TypeScript and Next.js codebase they control.

4. How often does Umbraco release breaking changes?

   Umbraco releases a new major version with breaking changes twice a year. Every fourth major is a long-term support release. Non-LTS versions get 9 months of support plus 3 months of security fixes; LTS versions get 24 months plus 12.

5. How much does Umbraco Cloud or Heartcore cost?

   Umbraco Cloud starts at €45 per month on Starter, which covers one Live environment; a development environment adds €45 per month. Standard is €280 per month, with a staging environment €70 per month on top, and Professional is €730 with staging included. Umbraco Heartcore starts at €60 per month (Starter), with Standard at €300 and Professional at €1,100. Umbraco raised its prices on January 1, 2026.

6. Can you migrate from Umbraco to Payload?

   Yes. You map Umbraco document types to Payload collections defined in TypeScript, write a script that imports content and media through Payload's API, rebuild the front end in Next.js, and put 301 redirects in place to preserve SEO.

7. How long does an Umbraco to Payload migration take?

   As a general guide, small and mid-size sites take three to six months and large, heavily customized sites take six to twelve. Those are rule-of-thumb ranges, and an experienced team often moves faster: WAYF migrated Ingersoll Rand's 20+ tenant, multi-thousand-page platform to Payload in five months.

Sources

• Umbraco 8 End-of-Life
• Umbraco 14 Release Candidate (new back office)
• Umbraco long-term support and end-of-life schedule — version types, release and EOL dates, including Umbraco 19’s scheduled release. Checked 11 September 2026.
• Umbraco XLTS — coverage blocks, security-patch-only scope and the no-gaps rule. Checked 11 September 2026.
• Umbraco 13 XLTS — Umbraco’s three options for 13 estates: upgrade, rebuild on 17 or later, or XLTS. Checked 11 September 2026.
• Umbraco 18 release — release date and STS status. Checked 11 September 2026.
• Umbraco upgrade documentation: choose the correct .NET version — CMS-to-.NET version table. Checked 11 September 2026.
• Umbraco breaking changes overview and Migrate content to Umbraco 15 — what changed in 14, 15 and 16. Checked 11 September 2026.
• Microsoft .NET support policy — .NET 8, 9 and 10 release and end-of-support dates. Checked 11 September 2026.
• Umbraco release schedule and versioning
• Umbraco pricing and Umbraco Cloud pricing — Cloud plan prices, and which environments each plan includes or sells as an add-on. Checked 11 September 2026.
• Umbraco annual price changes 2026
• Umbraco Heartcore pricing — Starter, Standard and Professional monthly prices. Checked 11 September 2026.
• Payload GitHub
• Payload
• Payload enterprise features — SSO, publishing workflows and audit logs as enterprise features, no published price. Checked 11 September 2026.
• Figma: Welcoming Payload