Migrating from TYPO3 to Payload: a 2026 guide for TYPO3 v12 end of free support

Free community support for TYPO3 v12 LTS ended on 30 April 2026. From 1 May 2026 the TYPO3 community no longer ships maintenance or security updates for it, so a v12 site now runs without free patches. That does not break the site the day the date passes, but it does start a clock, and unlike some end-of-life dates this one has more than one sensible answer.

If you run a TYPO3 v12 site, the useful thing this year is to understand the fork in front of you clearly, because TYPO3 gives you a real in-ecosystem path as well as an exit, and both are legitimate.

We are a React and Next.js shop, and we build on Payload CMS. We will be upfront about that bias throughout, and we will also be fair about where staying in the TYPO3 world is the better call, because for a lot of TYPO3 estates it is. This guide lays out the three real options, what makes a TYPO3 migration harder or easier than it looks, what a TYPO3 to Payload move actually involves, and how to decide.

Your three real options

TYPO3 gives you three genuine choices at v12 end of free support, and unlike some platforms the middle two are both worth taking seriously.

1. Upgrade to TYPO3 v13 or v14 LTS. This keeps you in the TYPO3 ecosystem, and there are two supported targets. TYPO3 v13 LTS receives free security updates until the end of December 2027. TYPO3 v14 LTS is the current flagship release, with bug fixes until December 2027 and free security updates until the end of June 2029, so it carries the longer runway of the two. Moving v12 forward is real work, but it is incremental work along a path TYPO3 designs for, not a rebuild onto a new architecture.
2. Buy paid ELTS as a bridge. TYPO3 GmbH sells Extended Long Term Support, a paid subscription that continues security and compatibility updates for a version after its free community support ends. For v12 it runs for three additional years, with an exclusive fourth year available to TYPO3 Partners, taking the safe-to-run window to 30 April 2030 at the outside. It is legitimate breathing room rather than a dead end, and it buys time to plan a larger move on your own schedule.
3. Replatform onto a different stack. If the reasons to leave TYPO3 are about more than this one deadline, end of free support is a natural moment to move. A headless CMS like Payload is the option in that category we know best.

The honest framing is that options one and two keep you on TYPO3, and only option three is a departure. That makes the decision less about the deadline and more about whether you want to stay on TYPO3 at all.

What makes TYPO3 estates sticky

Before weighing a departure, it helps to know what actually holds a TYPO3 site in place, because these are the things that size a migration.

TypoScript and Fluid do not port anywhere. TYPO3 is configured through TypoScript, its own declarative configuration language, and its pages are rendered through Fluid, its own templating engine. Neither has an equivalent you can carry across to another platform. On any move off TYPO3, the logic expressed in TypoScript and the templates written in Fluid are rebuilt rather than transferred.

The extension inventory is the audit that sizes the project. TYPO3’s capabilities come largely from extensions, installed from the TYPO3 Extension Repository or built in-house. A site’s real complexity lives in that list. Before any decision, inventory every extension, note which are actively maintained, which are custom, and which are load-bearing, because that inventory is the single best predictor of how much work any option involves.

Deeply nested page trees are a modelling question. TYPO3 organises content in a page tree that can grow deep and carry a lot of structure and logic in its hierarchy. Moving to a system built around structured content collections means deciding how that tree becomes types and relationships, which is a modelling exercise, not a copy.

Be fair to what TYPO3 does well

TYPO3’s multilingual and multi-site handling is genuinely strong, and it is a large part of why enterprises across the German-speaking market run it. Managing many sites and many languages from one installation, with fine control over how translations and site configurations relate, is something TYPO3 has done well for years and does not give up lightly. Any honest comparison starts by acknowledging that, because a team weighing a move needs to know it would be taking on that capability elsewhere rather than getting it for free. If multilingual, multi-site management at that level is the core of what your TYPO3 install does for you, that is a point in favour of staying, and it should be weighed before anything else.

TYPO3 is also free and open source under the GNU General Public License, actively maintained by a large community, with the paid ELTS and support offerings sitting alongside the free core rather than gating it. Leaving it is a choice about fit, not an escape from a licence.

What Payload actually is

Payload is an open-source CMS and application framework built on Next.js and TypeScript, actively maintained, MIT-licensed, and free to self-host with no per-seat or per-year platform fee. A few of its properties matter directly to a team weighing a move off TYPO3.

You model content in code. In Payload your collections, fields, and access control are written in TypeScript, in your repository, under version control. The shape of your content is the code itself, so it reviews, diffs, and deploys like the rest of the application, rather than living in a separate configuration language and admin schema.

Your CMS and front end are one project. Since version 3.0, released in November 2024, Payload installs directly into a Next.js app, so the CMS and the front end share a single codebase and ship in one deploy. For a team leaving PHP, TypoScript, and Fluid, that consolidates the stack onto one language across front and back end.

The stack is JavaScript and TypeScript. That is a feature if your team is already there or wants to be, and a cost if your people are deep in PHP and happy. Payload was acquired by Figma in June 2025 and remains open source and actively developed, so the project has a well-funded company behind it and an MIT licence that keeps the code yours regardless.

TYPO3 v12 vs v13 vs v14 vs ELTS vs Payload

	TYPO3 v12	TYPO3 v13 LTS	TYPO3 v14 LTS	TYPO3 v12 ELTS	Payload
Free support	Ended 30 Apr 2026	Security to Dec 2027	Security to Jun 2029	Paid subscription	Active, open source
Core stack	PHP	PHP	PHP	PHP	Next.js, TypeScript
Templating	Fluid / TypoScript	Fluid / TypoScript	Fluid / TypoScript	Fluid / TypoScript	Next.js (React)
Move required	Deadline passed	Incremental upgrade	Incremental upgrade	None (bridge)	Rebuild
Multilingual / multi-site	Strong, native	Strong, native	Strong, native	Strong, native	Built yourself or integrated
Licence	GPL, free core	GPL, free core	GPL, free core	GPL core + paid support	MIT, free
Lock-in	Ecosystem	Ecosystem	Ecosystem	Ecosystem	You own the code

The table is a starting point. The row that decides the most is “move required”: three of these options keep you on TYPO3, and only Payload asks for a rebuild, which is why the real question is whether you want to stay in the ecosystem. Among the in-ecosystem targets, v14 buys the longest free runway.

How a TYPO3 to Payload migration works

If you do decide to leave, the work breaks into five stages. None are exotic, and the first one determines how hard the rest will be.

Audit the TYPO3 instance first

Before any data moves, map what you have. The extension inventory is the centre of this: every extension from the repository, every custom extension, and what each one actually does. Alongside it, catalogue your content types, the shape of the page tree, every TypoScript configuration that carries real logic, the Fluid templates, third-party integrations, scheduled tasks, and the multilingual and multi-site setup. This audit is where the surprises live, and finding them now is far cheaper than finding them at cutover.

Map the page tree to Payload collections

In TYPO3 your content lives in the page tree and in extension records. In Payload it lives in collections, each defined as a TypeScript config with typed fields, relationships, and access rules.

The mapping is rarely one to one, and that is the opportunity. End of free support is a good moment to fix the content model you have meant to fix, so a deeply nested branch of the page tree becomes a lean collection plus relationships that reflect how the content is actually used now. A TYPO3 news record, for example, becomes a Payload collection:

import type { CollectionConfig } from 'payload'

export const News: CollectionConfig = {
  slug: 'news',
  admin: { useAsTitle: 'title' },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'body', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'authors' },
    { name: 'publishedAt', type: 'date' },
  ],
}

That config is the whole schema. It generates the database tables, the admin UI, and fully typed API responses, and it lives in your repository where it reviews and deploys with the rest of the code.

Migrate content and media

With the target collections defined, write a migration script that reads from TYPO3 and writes through Payload’s Local API, which lets server-side code query and create records directly with no HTTP round trip. You pull records from the TYPO3 database, transform each into the new shape, handle the multilingual variants explicitly so no language is dropped, and create them in Payload in code. Media moves to your chosen storage adapter, whether S3, Vercel Blob, or another provider, and the script rewrites references as it goes. Because the import runs through Payload’s own API rather than raw SQL, validation and hooks catch malformed legacy data during the migration instead of after launch.

Rebuild the front end in Next.js

If you are on Payload you are on Next.js, so the front end is a React application that reads content through the Local API. Fluid templates and TypoScript rendering logic do not port; they get rebuilt as React components. For a site with a well-defined set of templates this is predictable work, and it is usually the largest single chunk of the project. Rebuilding the multilingual and multi-site behaviour that TYPO3 gave you natively belongs here too, and it is real scope to plan for rather than assume.

Redirects, SEO, and QA

The migration is not done when the content lands. Map every old TYPO3 URL to its new path and put 301 redirects in place so you keep the search equity you have built. Carry over metadata, canonical tags, sitemaps, and structured data, taking particular care with per-language URLs. Then test against the old site page by page and language by language: content parity, redirects, forms, integrations, and Core Web Vitals. This stage protects the traffic that justifies the whole project, so budget real time for it.

How long it takes and what it costs

Migration timelines track complexity more than platform. As a rough guide, a small or mid-size TYPO3 site lands in the three-to-six-month range, and a large, heavily extended, multi-language build runs six to twelve months. The extension inventory and the number of active languages push a project up that range; a cleaner site with a tidy content model comes in lower.

The cost shape is worth being plain about. A migration is a one-time project cost, and staying on TYPO3 is not free either: a v13 or v14 upgrade is real engineering, and ELTS is a recurring paid subscription. Where Payload changes the ongoing math is that the core carries no licence fee, so after launch you pay for infrastructure rather than for support entitlements. Whether that saving is worth a rebuild depends heavily on how much you value TYPO3’s native multilingual and multi-site strengths, which you would be rebuilding.

Start planning early. Most teams want twelve to eighteen months of runway to handle discovery, the platform decision, the migration, and SEO preservation without rushing the cutover. Since v12 free support has already ended, ELTS or an upgrade to v13 or v14 is often the sensible bridge that buys that runway, whichever destination you ultimately choose.

When you should stay on TYPO3

Payload is not the right answer for everyone, and for a lot of TYPO3 estates staying is the better call. Four situations point that way.

1. You recently upgraded to v13 or v14. If you are already on v13 LTS you have free security support until the end of December 2027, and on v14 LTS until the end of June 2029. Either way there is no immediate pressure. Use that runway to plan deliberately rather than react to the v12 date.
2. Your extension estate is heavy but healthy. A large inventory of actively maintained, well-fitting extensions is an asset, not a liability. If it does what you need and stays current, rebuilding all of it elsewhere is a cost with no matching benefit.
3. You have an in-house TYPO3 team. If your engineers are productive in TYPO3, PHP, TypoScript, and Fluid, and hiring against that stack is easy for you, moving to TypeScript trades a comfortable team for a saving they may not value.
4. ELTS covers a roadmap you already have. If your plans run to 2027 or beyond and ELTS keeps v12 secure across that window, paying for the bridge can be the rational, low-disruption choice while larger decisions wait their turn.

So the choice comes down to fit. If TYPO3’s native multilingual and multi-site handling is central to what you do and your team is at home in the ecosystem, staying, whether on v13, v14, or ELTS, is a sound decision. If you would rather own your stack, write your content model in code, run your CMS and front end as one Next.js app, and consolidate onto TypeScript, that is the case for Payload, and it is the work we do.

Where WAYF fits

WAYF is an official Payload partner and Top Contributor, and we have built content platforms on Payload and Next.js for enterprises, public institutions, and high-growth teams. Migrating off legacy and end-of-life systems is a core part of what we do. TYPO3 end of free support is prompting the same review for a lot of teams this year, and we help them make the call honestly, including when staying on v13, v14, or ELTS is the right answer, and then run the migration when it is not: the audit, the content model, the data move with its languages intact, the Next.js front end, and the SEO-safe cutover.

If you are weighing an upgrade to v13 or v14, or ELTS, against a move to Payload, we will look at your actual TYPO3 instance and tell you which path fits.

Book a call and we will tell you if Payload is the right move for your site.

FAQ

1. When did TYPO3 v12 LTS reach end of support?

   Free community support for TYPO3 v12 LTS ended on 30 April 2026. From 1 May 2026 the TYPO3 community provides no further maintenance or security updates for it. Paid Extended Long Term Support (ELTS) from TYPO3 GmbH continues security fixes for several years beyond that date.

2. Should I upgrade to TYPO3 v13 or v14, or migrate away?

   All are valid. Both v13 and v14 LTS keep you in the ecosystem and are incremental upgrades rather than rebuilds. TYPO3 v13 LTS has free security support until the end of December 2027; TYPO3 v14 LTS is the current flagship and runs until the end of June 2029, so it buys the longer runway. Migrating away makes sense when your reasons to leave go beyond this one deadline. If TYPO3's multilingual and multi-site strengths are central to your site, upgrading is often the better call.

3. What is TYPO3 ELTS?

   ELTS, Extended Long Term Support, is a paid subscription from TYPO3 GmbH that continues security and compatibility updates for a TYPO3 version after its free community support ends. For v12 it runs three additional years, with an exclusive fourth year for TYPO3 Partners, taking the window to 30 April 2030 at the outside. It works as a legitimate bridge while you plan a larger move.

4. Can you migrate from TYPO3 to a headless CMS like Payload?

   Yes. You audit the extension estate, map the page tree to Payload collections defined in TypeScript, write a migration script that imports content and media through Payload's API with the languages handled explicitly, rebuild the front end in Next.js, and put 301 redirects in place to preserve SEO.

5. How long does a TYPO3 to Payload migration take?

   As a general guide, small and mid-size sites take three to six months and large, heavily extended, multi-language sites take six to twelve. The extension inventory and the number of active languages are the main drivers.

6. Is Payload CMS free?

   Payload is open source under the MIT licence and free to self-host. You pay only for your own infrastructure, such as database, file storage, and Node hosting. There is no per-year platform licence fee. TYPO3's core is likewise free and open source under the GPL; its paid ELTS and support sit alongside the free core.

---

Sources: TYPO3 v12 LTS end of free support, TYPO3 ELTS for v12.4, TYPO3 v13 LTS release announcement, TYPO3 v14 LTS release announcement, TYPO3 Development Roadmap, TYPO3 open source licenses, Payload GitHub, Payload, Figma: Welcoming Payload.