Migrating from FirstSpirit to Payload: a guide for institutional and enterprise teams

FirstSpirit runs large editorial estates, particularly across the German-speaking market, and it can be deployed as FirstSpirit Cloud or self-hosted on-premises. A replatforming review can start for ordinary reasons: the front end moves to React, content has to serve channels the current templates were never built for, or a licence renewal prompts someone to compare what the platform costs against the parts of it the organisation uses.

This guide describes what moving that estate to Payload involves. There is no end-of-life date driving this decision. The guide is written for the case where the answer turns out to be yes, and it is equally clear about the parts where the answer is no.

Where FirstSpirit sits

FirstSpirit is an enterprise CMS with two editing clients rather than one. SiteArchitect is the full client, documented for editors and project developers; ContentCreator is the browser-based editing interface, carrying the functions relevant to daily editorial work. Projects are built through template development, and the documentation set is organised around that split, with separate manuals for template development in each client.

That two-client structure matters to a migration for a practical reason. Editorial habits formed in ContentCreator and the technical model maintained in SiteArchitect are different surfaces of the same project, and a replacement has to answer both. Payload’s admin panel is a React application in your own codebase, which covers the editing surface, while the model that SiteArchitect maintains becomes TypeScript configuration in the repository.

Who you are buying from now

FirstSpirit has changed hands twice. In March 2021 adesso sold e-Spirit AG, the company that developed FirstSpirit, to Crownpeak Technology Inc. The product site, firstspirit.com, now calls FirstSpirit “a Rezolve Ai solution”, and its imprint names Crownpeak Technology GmbH in Dortmund as the operator, with the copyright line “Crownpeak Technology GmbH (a Rezolve Ai company)”. The documentation home at docs.e-spirit.com redirects to docs.crownpeak.com, where the product is listed as Crownpeak CMS (FirstSpirit). Individual manuals are still served from docs.e-spirit.com, carry the copyright line of Crownpeak Technology GmbH, and identify the current release as FirstSpirit 2026.9.

The CaaS product documentation, version 21.4.0 dated 1 September 2026, carries Rezolve AI in its header. Its legal information states that CaaS is a product of Crownpeak Technology GmbH and that only the licence agreed with Crownpeak Technology GmbH applies to the user, and its help section names the technical support of Rezolve AI for any topic related to the FirstSpirit product.

None of this is an argument for leaving. Ownership changes are not a defect, and a platform under new ownership can be well maintained. It does mean one piece of homework: confirm which legal entity your contract, support agreement and data-processing terms name, because that is the party you would be negotiating a renewal with.

FirstSpirit is a platform before it is a CMS

The estate often extends beyond content. The documentation set covers Fredhopper for on-site search and merchandising, the Digital Quality Manager for accessibility, SEO and page-speed monitoring, Experience Orchestrator for personalisation and recommendations, and the Digital Governance tools for cookie consent and third-party technology control. Around the CMS itself sit TranslationStudio with connectors for Across, SDL and memoQ, Multisite Management, the Navigation Service, the Omnichannel Manager, and commerce connectors for SAP Commerce Cloud and Salesforce.

Payload replaces the content layer. Everything in that list needs its own decision: keep it, replace it, or drop it because the organisation stopped using it years ago. The audit that separates the content layer from the rest is what decides whether this is a CMS migration or a programme, and it belongs at the start.

How content comes out

The route with the most obvious name is the one to rule out first.

External Synchronization is for templates. Its documentation is explicit: it must only be used to distribute and synchronize templates together with the dependent elements the development process needs, it recommends ContentTransport for distributing editorial content, and it states that External Synchronization is not designed to transport mass data, with datasets and database content named specifically. Using it from external tooling such as FSDevTools also requires the API-Access licence feature. ContentTransport, which the restrictions page recommends instead, moves content between FirstSpirit projects as features, so it serves a move within FirstSpirit.

The REST API is documented at alpha status. The FirstSpirit REST API installation page describes the module as in active development, tells you it should only be used for testing and development purposes, instructs you not to use it on a production server, and notes that the alpha release has not undergone security testing and should not be exposed to public networks. An extraction built on the REST API would depend on an alpha module that has not undergone security testing.

CaaS is the delivery layer, and it does not carry history. Content edited in FirstSpirit is transferred to the CaaS platform, which exposes the data over a REST and GraphQL interface with filter and projection options, secured with API keys. The product documentation states that preview and release data are stored separately and that historical data is not available via the CaaS platform. CaaS Connect, which superseded the older CaaS module in July 2020, produces a unified JSON schema for all FirstSpirit content with a URL scheme based on FirstSpirit UUIDs.

The Java Access API is documented by the vendor as one of FirstSpirit’s most important interfaces, held to its highest stability requirements. An extraction built on it means writing and maintaining code against it.

The practical consequence is that the extraction route has to be chosen against the inventory and validated on real content before anyone commits to a cutover date.

The editorial guarantees you cannot afford to lose

German institutional teams arrive at this conversation with specific expectations: an approval chain with named roles, a record of who released what, and versioning they can point an auditor at. Those expectations are reasonable, and the migration plan has to meet each of them.

FirstSpirit ships two standard workflows, Assign task and Request release, and the release request puts a check between an editor’s change and live transmission. FirstSpirit’s licence file sets the boundary: with license.WORKFLOW at 0, only those standard workflows can be used, and creating or using any other workflow requires the value 1. The BasicWorkflows module, which supplies common release and delete logic as workflows imported into the project, states that it needs the value 1 and FirstSpirit 2022.3 or later. FirstSpirit publishes no price for the parameter. On the Payload side, publishing workflows are a licensed enterprise feature with no published price, and the alternative is to build the approval gate on the open-source core’s drafts, versions and access control.

A team that relies only on FirstSpirit’s standard release request is moving from a gate included in the product to one it has to license or build. A team running custom approval chains already holds the licence parameter for them, and on Payload faces a choice between the enterprise licence and an implementation that lives in the application repository and ships through code review like the rest of the application. Payload’s access control serves that implementation, because access rules are functions evaluated per collection, per field and per user. Decide which route applies, and price it, before the build starts.

Version history needs the same treatment. FirstSpirit creates a new version each time an editor changes an object, with a history of which changes were made by which persons, and its historization can temporarily reinstate a read-only state of the whole project as of a past date. Payload can retain and compare document versions once versioning is enabled, but that covers the history you create from the migration onwards. Existing FirstSpirit revisions and release records need an explicit decision: extract and map them, retain them in a readable archive, or accept their loss in writing. CaaS will not supply them, and the decision is much cheaper to make before the old system is switched off.

What stays behind

• The surrounding products. Fredhopper, DQM, Experience Orchestrator and the Digital Governance tools are separate products with separate jobs, and each needs a replacement or a retirement decision.
• Translation workflow. TranslationStudio’s connectors to Across, SDL and memoQ represent a working relationship with translation agencies. Content can be modelled and localised in Payload, and the agency workflow around it has to be rebuilt deliberately.
• Commerce integration. The SAP Commerce Cloud and Salesforce connectors deliver FirstSpirit content into those storefronts; on Payload that delivery is rebuilt as an integration.
• Template logic. FirstSpirit templates and their rendering are not portable to Payload. The content model can be mapped; the presentation layer is rebuilt in the frontend framework you move to.
• Historical revisions and historization, unless they are extracted deliberately, as described above.

What the migration involves

The work starts with an inventory of content types, sites and languages, checked against what the chosen extraction route reaches. It then covers a mapping of content types to Payload collections with rich text converted to Lexical, a decision on the approval gate and its cost, a retention plan for history, a rebuild of the frontend against Payload’s APIs, and a redirect map that preserves the URLs the organisation has earned.

The sequence runs from discovery that establishes what the route reaches, to mapping, to a rehearsal against production-scale content, and then to cutover. Our pre-migration checklist covers the project-plan shape this fits into.

How we approach this

WAYF builds content platforms on Payload and Next.js, and runs migrations off enterprise CMS platforms into them. WAYF is an official Payload partner and top contributor, so we have an interest in this recommendation. When the better answer is that an organisation should stay on FirstSpirit and renegotiate its licence, that is the answer we give.

If you are weighing this decision, the useful first step is the inventory: what the estate contains, which extraction route reaches it, and what the approval and retention requirements are. That inventory is what a fixed price is quoted against. Book a call and we will go through it with you.

Sources

The FirstSpirit capability claims above are taken from the vendor’s own documentation, and the Payload ones from Payload’s, checked on 10 September 2026, with the ownership, workflow and versioning sources rechecked on 11 September 2026:

• Crownpeak CMS (FirstSpirit) documentation portal — product naming, deployment options, the client descriptions, the Access API, the surrounding product set
• firstspirit.com imprint — the operating company and its Rezolve Ai relationship
• adesso press release, 19 March 2021 — the sale of e-Spirit AG to Crownpeak Technology Inc.
• FirstSpirit External Synchronization: Restrictions — templates only, ContentTransport for editorial content, not for mass data
• FirstSpirit External Synchronization: Introduction — the API-Access licence requirement, FirstSpirit 2026.9
• FirstSpirit REST API: Installation & Configuration — alpha status and the production warning
• CaaS product documentation — REST and GraphQL over API keys, separate preview and release data, no historical data, CaaS Connect
• FirstSpirit licence configuration — what license.WORKFLOW at 0 and 1 permits
• FirstSpirit standard workflows and releasing objects — the Task and Request release workflows
• BasicWorkflows documentation — the module’s license.WORKFLOW requirement and version prerequisites
• The FirstSpirit concept — versioning and historization
• FirstSpirit Access API: FeatureAgent — content transport features between projects
• FirstSpirit Connect for SAP Commerce Cloud — content transfer into the storefront
• Payload access control, Payload versions and Payload enterprise features — function-based access control, opt-in versions, and publishing workflows as a licensed feature

FAQ

1. How do you get content out of FirstSpirit?

   Not through External Synchronization, despite the name. Its documentation states it must only be used to distribute and synchronize templates, recommends ContentTransport for editorial content, and says it is not designed to transport mass data. The FirstSpirit REST API is documented at alpha status, with the instruction not to use it on a production server. That leaves CaaS, which exposes REST and GraphQL over API keys, and the Java Access API. Pick and validate the route against the migration inventory before committing to a plan.

2. Does CaaS carry the full history?

   No. The CaaS product documentation states that preview and release data are stored separately and that historical data is not available via the CaaS platform. If old revisions or approval evidence have to survive the migration, they need their own extraction and retention plan, agreed before FirstSpirit is decommissioned.

3. Can Payload reproduce FirstSpirit's approval chains?

   FirstSpirit ships a standard Request release workflow that puts a check between an editor's change and live transmission, and that workflow runs with the license.WORKFLOW parameter set to 0. Creating or using workflows beyond the standard ones, including the BasicWorkflows module, needs that parameter set to 1, and FirstSpirit publishes no price for it. Payload licenses publishing workflows as an enterprise feature with no published price, and the alternative is to build the approval gate on the open-source core's drafts, versions and access control, keeping the rule in the same repository as the rest of the code. Price whichever route applies during scoping.

4. Who owns FirstSpirit now?

   FirstSpirit is published by the Dortmund-based Crownpeak Technology GmbH, which the product site firstspirit.com describes as a Rezolve Ai company. The documentation portal at docs.crownpeak.com lists the product as Crownpeak CMS (FirstSpirit), and the CaaS product documentation dated 1 September 2026 names Crownpeak Technology GmbH as the licensor and Rezolve AI as the provider of technical support. Check which entity your own contract, support agreement and data-processing terms name before planning anything around them.

5. What does not move from FirstSpirit to Payload?

   The products around the CMS. Fredhopper search and merchandising, the Digital Quality Manager, Experience Orchestrator, the Digital Governance tools, TranslationStudio and its translation-agency connectors, Multisite Management and the commerce connectors for SAP Commerce Cloud and Salesforce each need a replacement decision of their own. Payload replaces the content layer, and the surrounding products stay on the list as separate decisions.