Migrating from Sitefinity to Payload: a 2026 guide for multi-brand teams

If your company runs more than one brand site on Progress Sitefinity, the cost of the platform grows with the number of brands. Sitefinity licenses per production domain. One licence covers one production domain, and each additional brand site you publish needs its own paid add-on licence. The model scales in the wrong direction for a business that keeps adding brands, regions, or campaign sites.

That is the starting point for a lot of teams who begin looking at alternatives. There is no end-of-life cliff forcing the question. Sitefinity’s long-term-support releases are supported for years, and the current 15.x line runs well into the future. What prompts the review is usually something concrete: an upgrade falls due, a new brand site would mean another licence, or a renewal lands on the desk and the total has crept up again.

This is written for teams at that point, weighing another licence cycle against a different kind of platform. We are an official Payload partner, and we have put more than 20 brand tenants on a single Payload build, so we have a clear view of how this move tends to go, including the cases where Sitefinity is the better choice and we say so.

The licensing model, and why multi-brand teams feel it most

Sitefinity’s licensing is domain-based. A single licence registers one production domain, such as yourbrand.com. You can spin up unlimited non-production subdomains for development and staging, which is generous, but the production rule is the one that shapes your bill. The moment you launch a second brand on its own domain, that site needs an additional production-domain licence.

For a single-site business this is a non-issue. For a group running a portfolio of brands, regional sites, or acquired properties, it becomes a recurring tax on growth. Every new brand you bring onto the platform is another licence to buy and maintain, on top of the build work to stand the site up. The licensing grows with your brand count rather than your traffic or your value.

The headline numbers give a sense of scale, though they come from resellers and third-party analyses rather than a public Progress rate card, so treat them as indicative. A single-domain Sitefinity licence supporting up to ten back-end users tends to sit around $10,000 to $12,000 a year. Configurations with more domains and users climb to roughly $30,000 to $35,000 and up. Sitefinity Cloud, the managed software-as-a-service option that bundles hosting, lands near $35,000 a year. Each additional brand raises that base figure.

You pay for the licence and still build the site

The second thing that wears on teams is the gap between paying for a licensed platform and the amount of development the platform still asks of you.

Sitefinity is frequently described as light on out-of-the-box capability. Standing up anything beyond a basic site takes genuine .NET development, and custom widgets, templates, and integrations are standard on any non-trivial build. That is fine in itself, since most serious sites need engineering. The friction is that the engineering happens against documentation that users routinely call hard to navigate, and a community that is small compared with mainstream stacks, so answers are harder to find when something breaks.

Put those together and a pattern emerges. You are paying a per-domain licence, employing or contracting .NET developers to build and maintain the sites, and working around thin support resources while you do it. Once the bulk of the value is coming from your own engineering rather than the platform’s built-in features, it is worth asking what the licence is buying.

What Payload is, and what changes

Payload is an open-source CMS and application framework built on Next.js and TypeScript. For a Sitefinity team, a few differences matter most.

The content model lives in code. You define collections, fields, and access rules in TypeScript, in your repository, so the schema is version-controlled and ships through your normal pull-request and deploy process rather than being configured inside a platform back office. Since version 3.0, released in November 2024, Payload installs directly into a Next.js application, which keeps the CMS and the front end in one project, and a Local API lets server code read content without an HTTP round trip.

The licensing model is the part that speaks directly to the multi-brand problem. Payload is MIT-licensed and free to self-host, with no per-domain or per-site fee. One Payload instance can serve many brands as separate tenants, each with its own content, users, and access boundaries, behind a shared codebase. Adding a brand becomes a configuration and build task, with no new licence to buy.

The stack is mainstream. Next.js, React, and TypeScript have large communities and deep documentation, so the support problem that comes up with Sitefinity is much less of an issue, and hiring against the stack is straightforward. On the question of who stands behind the project, Payload was acquired by Figma in June 2025 and continues as an actively developed open-source product.

Sitefinity versus Payload

	Progress Sitefinity	Payload
Licensing	Commercial, per production domain	Free, MIT, no per-site fee
Multi-brand	Add-on licence per brand site	Many tenants on one instance
Cost (indicative)	~$10K to $35K+/yr, plus per domain	Infrastructure only
Core stack	.NET	Next.js, TypeScript
Content model	Configured in the back office	Defined in code, version-controlled
Front end	ASP.NET Core Renderer / MVC	Next.js (React)
Out of the box	Light; custom build expected	Light; custom build expected
Community / docs	Smaller, harder to navigate	Large Next.js and React community
Support status	LTS supported for years	Active

Two rows carry the decision. The licensing and multi-brand lines are where Sitefinity and Payload diverge most for a portfolio business, and the out-of-the-box row is where they are similar, since both expect real development. If you are building custom either way, the platform that does not charge per brand site changes the long-run total.

How a Sitefinity to Payload migration works

The migration runs through these stages. Scoping the multi-site picture early matters more than usual here, because how your brands and domains are arranged drives the shape of the whole project.

Map the sites before the content

Begin with an inventory that pays special attention to structure. Record every site and production domain, the content types and widgets behind them, the templates and the ASP.NET Core Renderer setup, the Sitefinity modules in use, and any shared content across brands. The arrangement of sites and domains determines how you model tenants in Payload, so getting this picture right at the start saves rework later. This is also where you decide which brands move together and which content is genuinely shared versus merely duplicated.

Model content types as Payload collections, with tenants

Sitefinity organises content as content types and widgets, configured in the platform and scoped to sites. Payload uses collections, each a TypeScript config that declares its fields, relationships, and access rules. To carry the multi-brand structure across, you add a tenant relationship to the collections that belong to a brand, and a legacyId so each record can be traced back to its Sitefinity source:

import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: { useAsTitle: 'title' },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true },
    { name: 'legacyId', type: 'text', required: true, unique: true, index: true },
    { name: 'legacyPath', type: 'text' }, // old URL, kept for 301s
    { name: 'brand', type: 'relationship', relationTo: 'brands', required: true },
    { name: 'body', type: 'richText' },
    { name: 'layout', type: 'blocks', blocks: [/* your section types */] },
  ],
}

A brand relationship plus access rules scoped to it gives each tenant its own content and editorial boundary inside one instance, which is the part Sitefinity charges a separate licence for. Payload’s multi-tenant plugin handles the common cases, and the Sitefinity widgets you rebuild map onto Payload’s blocks field.

The plain content types move quickly. The effort concentrates on the parts with no clean equivalent. Sitefinity’s dynamic modules become custom collections, Sitefinity Forms needs a form solution on the new stack, and we rebuild any personalisation rules tied to Sitefinity Insight against your chosen tools rather than carrying them across. Scope the project around those, not the standard pages.

Move the content and media

With collections defined, a migration script reads from Sitefinity and writes through Payload’s Local API. Sitefinity exposes content through its OData web services, which you query, reshape, and load into Payload, mapping each source site onto its tenant as you go:

import { getPayload } from 'payload'
import config from '@payload-config'

const payload = await getPayload({ config })

for (const item of sitefinityItems) {
  const data = {
    title: item.Title,
    slug: item.UrlName,
    legacyId: item.Id,
    legacyPath: oldPathFor(item), // keep the old URL for 301s
    brand: brandIdFor(item.SiteId),
    body: convertHtml(item.Content),
  }

  // Upsert on legacyId so the load is idempotent and safe to re-run
  const existing = await payload.find({
    collection: 'pages',
    where: { legacyId: { equals: item.Id } },
    limit: 1,
  })

  if (existing.docs[0]) {
    await payload.update({ collection: 'pages', id: existing.docs[0].id, data })
  } else {
    await payload.create({ collection: 'pages', data })
  }
}

Carrying the legacyId and upserting on it keeps the load idempotent, so a re-run updates records rather than duplicating them, and that same id is what later wires up relationships between documents and per-URL redirects. One practical detail: Sitefinity’s OData services default to a maximum of 50 items per query, so the script pages through larger content sets rather than pulling everything in one call. Media transfers to your chosen storage adapter, with the script rewriting references as it runs. Because each record goes through Payload’s API rather than a direct database write, validation and hooks run on everything, so malformed legacy content shows up during the migration rather than after launch.

The convertHtml() call in that snippet carries the real cost of the content move. Sitefinity stores rich text as HTML and Payload stores it as Lexical, a typed JSON tree, and the two do not map cleanly: inline styles, embeds, and widget markup have no direct Lexical equivalent. It is the step teams most often underestimate, so scope it deliberately rather than treating it as a one-line conversion.

Rebuild the front end in Next.js

We rebuild Sitefinity’s front end, whether on the ASP.NET Core Renderer or older MVC, as a Next.js application reading from the Local API. For a multi-brand setup, the front end resolves the incoming domain to a tenant and serves that brand’s content, which is how one codebase drives many sites. A team already fluent in React will be on home ground here, and with a defined set of templates the work is straightforward to estimate across brands.

Redirects, SEO, and sign-off

Each brand site keeps its own URL structure, so every old Sitefinity URL needs a 301 redirect to its new path, per domain, along with metadata, canonical tags, sitemaps, and structured data. The new sites are then checked against the old ones brand by brand, covering content parity, redirects, forms, integrations, and Core Web Vitals, so the search visibility of every property survives the move.

How long it takes and what it costs

Timelines track the number of brands and the depth of customisation more than anything else. A single content-led site usually runs three to six months. A multi-brand portfolio with shared content and many integrations runs longer, into six to twelve months or beyond, depending on how many sites move and how much is genuinely shared. Treat those as rough brackets. A team that has done multi-tenant migrations before tends to come in lower, which is what the Ingersoll Rand project below shows.

On cost, the move removes the per-domain licensing entirely. You replace a commercial licence that grows with your brand count with a free, MIT-licensed CMS and the infrastructure you run. For a portfolio business, the saving compounds with every brand, because each one no longer carries its own licence. The migration is a one-time cost, and the brands that follow are build work on a platform you own rather than another licence to buy.

One cost sits outside engineering. Editors who know the Sitefinity back office have to learn Payload’s admin, so plan for some training and a short slowdown in publishing as each brand goes live and the team settles in.

Ingersoll Rand is the clearest illustration of the structure this unlocks. When Oracle moved to discontinue Oracle Content Manager, the company’s China sites needed a new platform on a fixed deadline. We delivered it on Payload in five months, running more than 20 brand tenants on a single instance, with thousands of pages and tens of thousands of media assets and redirects moved across, and the live platform stayed up throughout. The Ingersoll Rand case study covers the architecture in detail. The same multi-tenant model is the direct answer to paying a licence per brand.

When you should stay on Sitefinity

Sitefinity is a capable platform, and there are clear cases where staying is the better call.

If your marketing team relies on Sitefinity Insight and the built-in personalisation and campaign tools, those are doing work that Payload does not include out of the box, and replacing them means adding separate services. A single-brand business feels none of the per-domain pressure that drives the multi-brand case, so for one site on a current LTS release, the licensing argument largely falls away. And if you want Progress to own hosting, scaling, and uptime under a contractual SLA, Sitefinity Cloud provides that, where a self-hosted Payload stack puts the infrastructure in your hands in exchange for removing the licence.

The decision tends to come down to brand count and where your engineering already goes. A single-brand .NET shop that leans on Sitefinity’s built-in marketing tools has little reason to move. A multi-brand business that is already building custom in .NET, and paying another licence with every brand it launches, is the profile that gains most from a code-first platform with no per-site fee. That second case is the one we build for.

How WAYF can help

WAYF is an official Payload partner and Top Contributor, building Payload and Next.js platforms for Fortune 500 companies, public institutions, and fast-growing teams. Multi-tenant and multi-brand architecture is core to what we do, the Ingersoll Rand build among them. Much of our work is migration off licensed and legacy systems, including Oracle Content Manager, WordPress VIP, and Wagtail.

If you are weighing another Sitefinity licence cycle against a move to Payload, we will look at how your brands and domains are arranged and tell you whether a single multi-tenant instance fits, including the cases where staying on Sitefinity is the better call.

Book a call, and we will tell you whether moving off Sitefinity makes sense for your brands.

FAQ

1. How does Sitefinity licensing work?

   Sitefinity licenses per production domain. A single licence covers one production domain, and additional production domains, which usually means additional brand sites, require add-on licences. Non-production subdomains for development and staging are unlimited.

2. Does Sitefinity charge per domain or per brand site?

   Per production domain, which in practice means per brand site. Running several brands on their own domains requires a licence for each, so the cost rises with the number of brands you publish.

3. How much does Sitefinity cost?

   Progress does not publish a public rate card, so figures are indicative. Reseller and third-party estimates put a single-domain licence with up to ten back-end users around $10,000 to $12,000 a year, higher tiers at roughly $30,000 to $35,000 and up, and Sitefinity Cloud near $35,000 a year including hosting.

4. Is Sitefinity open source?

   No. Progress Sitefinity is a commercial, licensed .NET CMS. Payload, by contrast, is open source under the MIT licence and free to self-host.

5. When do Sitefinity versions reach end of life?

   Sitefinity releases move through Active, Sunset, and Retired phases. Long-term-support releases are supported for at least four years, and the current 15.x LTS line runs well into the future. Retired versions no longer receive patches or security fixes.

6. Can you migrate from Sitefinity to Payload?

   Yes. You map Sitefinity content types and sites to Payload collections and tenants defined in TypeScript, move content and media through Payload's API, rebuild the front end in Next.js with domain-to-tenant routing, and add 301 redirects per brand to preserve SEO.

7. How long does a Sitefinity to Payload migration take?

   A single site usually takes three to six months. A multi-brand portfolio takes six to twelve months or more, depending on how many sites move.

Sources

• Progress Sitefinity lifecycle policy
• Sitefinity license model overview
• Sitefinity how to buy and editions
• Sitefinity headless API (OData content)
• Smooth Fusion: Sitefinity licensing and pricing overview
• Eveliko: CMS pricing 2026
• Americaneagle: Sitefinity version history
• Payload GitHub
• Payload
• Figma: Welcoming Payload