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

If you run an Umbraco site, the next deadline on your calendar is December 2026, when Umbraco 13 reaches the end of its long-term support (LTS). Before that, 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 to the latest version, Umbraco 17. That is a reasonable move, and for plenty of teams it is the right one. This guide makes the case for the other option, which gets discussed far less: stepping off the .NET upgrade cycle entirely and rebuilding on Payload, a CMS you write in code and run as part of your own application.

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.

There is a second cost folded into that. In Umbraco, a major CMS upgrade is also a .NET upgrade, because the two move together. Umbraco 13 runs on .NET 8, and Umbraco 17, the current LTS, runs on .NET 10. Moving between them is a runtime upgrade as much as a CMS one, and it waits on any third-party packages that have to catch up first. Teams running several Umbraco sites, each customized differently, feel this most, because every site is its own upgrade project.

Umbraco 14 in 2024 showed how deep these 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 real subscription costs. Umbraco Cloud, the managed platform that handles hosting, automated upgrades, and staging environments, starts around $55 per month and climbs through Standard and Professional tiers as your site grows; the Standard plan sits near €280 per month. Umbraco Heartcore, the headless software-as-a-service option, starts in the region of $49 to $75 per month depending on tier. 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 real 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. What differs is the shape of that work. Payload upgrades are a package update and a database migration that you run and review like any other code change, rather than a platform-wide version jump that drags your runtime and your CMS forward together. The work stays inside your own application, on your own schedule, rather than tracking a vendor’s release calendar.

Umbraco 13 vs Umbraco 17 plus Heartcore vs Payload

	Umbraco 13 (LTS)	Umbraco 17 + Heartcore	Payload
License	Free, MIT (core)	Free core; Heartcore from ~$49 to $75/mo	Free, MIT
Hosting	Self-host or Umbraco Cloud	Umbraco Cloud / Heartcore SaaS	Self-host (any Node host)
Core stack	.NET 8	.NET 10	Next.js, TypeScript
Content model	Document types in back office	Document types in back office	Collections defined in code
Headless	Add-on / Content Delivery API	Heartcore (native headless)	Native, API-first
Front end	Razor / MVC	Razor or headless front end	Next.js (React)
Upgrade shape	Major + .NET upgrade, breaking changes	Major + .NET upgrade, breaking changes	Package update plus migration
Support status	LTS until Dec 2026	Current LTS	Active

This compares the options at a glance. 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.

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 a single up-front cost, and after it you are paying for infrastructure you already understand, a database, file storage, and Node hosting, while upgrades turn into ordinary application maintenance instead of a platform migration that comes around again every couple of years.

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 December 2026 date is close enough that the window is already narrowing, so the sooner the decision is made the better, whichever way it lands.

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 stop treating CMS upgrades as a recurring migration, 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 the current long-term support version, built on .NET 8, and is supported until December 2026. After that it stops receiving security fixes. Umbraco 8 already reached end of life on February 24, 2025.

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 couples each CMS upgrade to a .NET upgrade, 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 around $55 per month and rises through higher tiers, with the Standard plan near €280 per month. Umbraco Heartcore starts around $49 to $75 per month depending on tier. 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 Long-term Support and End-of-Life
• Umbraco 8 End-of-Life
• Umbraco 14 Release Candidate (new back office)
• Umbraco release schedule and versioning
• Umbraco pricing
• Umbraco annual price changes 2026
• Umbraco Heartcore pricing
• Payload GitHub
• Payload
• Figma: Welcoming Payload