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

CoreMedia Content Cloud runs large editorial estates, including in the German-speaking market. A replatforming review can start when the front end moves to React, when content has to serve additional channels, or when the organisation weighs its platform licence against the capabilities it uses. Editorial governance has to remain part of that decision.

This guide describes what moving that estate to Payload involves. It 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 CoreMedia sits

CoreMedia is a Hamburg company, and the product line is documented as the CoreMedia Experience Platform, with CoreMedia Content Cloud as the content product. The current documented release line is CMCC 13, alongside published documentation for CMCC 12, 11 and 10.

The Studio user manual describes a CoreMedia installation as two separate systems. Content is produced on the production system, where changes have no direct effect on the websites readers can reach, and those changes become visible only once they are approved and published to the live system. Publication is a transfer between systems.

Editors work on content items: a Picture item holding the image together with its describing text and metadata, an Article item holding the article text and its teaser, linked to each other so that a site is assembled by combining them. Those items sit in a folder hierarchy, and typed items such as CMArticle, CMPicture and CMChannel come from the Blueprint document model.

Payload’s standard drafts model keeps draft and published states within the same database, so it does not reproduce CoreMedia’s production-to-live transfer by default. Content types map to collections and relationships. Payload also has configurable, nested folders for organising documents across collections; map the existing hierarchy and its rights rules explicitly rather than assuming the two folder systems behave identically. These choices determine which parts of the estate can be transferred and which need new implementation.

CoreMedia is a platform before it is a CMS

The Studio user manual documents features well outside content management: Elastic Social with user profiles, comment moderation and user-generated content; commerce editing including category hierarchies, shoppable videos and 360-degree views; and a Content Hub for pulling in external assets.

An estate that uses those features needs each layer scoped. The content layer can move to Payload. The commerce and community layers move to whatever the organisation chooses next, or they stay where they are. A combined proposal needs to account for those decisions and integrations in its estimate.

The first step is an audit that separates the content items from everything the platform does around them. That audit decides whether this is a CMS migration or a programme.

How content comes out of CoreMedia

One extraction route uses the CoreMedia Headless Server. It serves GraphQL at /graphql, with an interactive GraphiQL endpoint at /graphiql in preview mode. Media objects take a different path: the manual states they are delivered over REST, inspectable through Swagger UI at /swagger-ui/index.html when it is configured. An export script using this route therefore handles both content queries and media downloads.

The schema file content-schema.graphql defines a subset of the CoreMedia Blueprint content model, and Blueprint content types are mapped to GraphQL interfaces of the same name. A generic headless export reaches what that schema exposes. Anything a project added to the document model over the years reaches the export only if the schema was extended to cover it.

Budget discovery time for reading the deployed schema against the deployed content model. On an estate that has been live for a decade, the gap between the two is where migration timelines go.

CoreMedia also documents cm serverexport, which exports repository content to XML. Its limits matter: only the latest content version is exported, metadata such as the last modification date and publication status is omitted, and empty folders are not exported. These XML files need a transformation and import process for Payload. Choose the route against an inventory of required fields, locales, assets, relationships and publication states; neither route should be assumed to deliver a complete historical archive.

The content model, concept by concept

Blueprint content types become Payload collections defined in TypeScript. CMArticle and its siblings map to collections with typed fields; CMPicture maps to an upload-enabled collection; CMChannel, which carries page and navigation structure, usually splits into a collection for pages and explicit relationship fields for navigation.

Struct properties and link lists have close counterparts in Payload’s group and relationship fields. Rich text is the field type that needs the most handling, because CoreMedia stores its own rich-text markup and Payload stores the Lexical format, so moving it is a transformation step rather than a copy.

CoreMedia lets editors arrange content into a page grid layout. Payload’s blocks field offers an ordered list of named block types, but the layout rules and front-end rendering still need to be implemented. Inventory the grid variants in use, agree which map to shared blocks, and verify the result against representative pages.

The editorial guarantees you cannot afford to lose

CoreMedia documents two publication workflows. Direct Publication approves and publishes everything in the workflow in one step. Reviewed Publication, in the manual’s own words, “requires interaction between two content editors. One editor starts the workflow while the second editor has to approve the publication.” A team that has run on Reviewed Publication has a four-eyes rule written into its process, and often into an audit obligation.

Versioning works on check-out and check-in: the manual states that each time a content item is checked out and changes are applied, a new version is created. Editors can compare two versions and create a new version based on an older one, and a previous version cannot be edited directly. Rights are managed through a rights system with folder-level rules, and the editorial consequences are documented plainly, down to content items a user can see but not publish.

Payload’s open-source core carries document version history, drafts, and function-based access control that can express per-field, per-user and per-document rules in TypeScript, with no per-seat charge on editor accounts. Enable and test those features against the roles and actions the editors need. They provide capabilities for the new system; existing CoreMedia revisions, timestamps and approval evidence require a separate extraction-and-mapping or readable-archive plan. Agree retention requirements and verify access to historical records before decommissioning the source.

Four-eyes publication needs an explicit implementation choice. Payload offers publishing workflows and SSO as enterprise features through its sales team. An alternative is to build the approval gate on the core’s drafts, versions and access control, keeping the rule in the same repository as the rest of the code. Verify that the chosen route prevents self-approval and enforces the rule through every write path. The core’s document versions provide change history; wider audit requirements, such as login and administrative events, need their own scope and retention checks. Price the features and implementation that the estate requires during scoping.

What stays behind

Payload’s standard drafts model has no built-in equivalent to CoreMedia’s publication transfer between production and live systems. Teams whose approval process depends on that boundary need to verify whether drafts and access control meet the requirement or whether a separately designed delivery boundary is needed.

Elastic Social does not travel. Comment histories, moderation state and user profiles belong to that component, and an organisation that needs them keeps them or replaces them.

Commerce integration does not travel. Category hierarchies, shoppable video and the LiveContext integrations with commerce suites are outside what a CMS provides. Where commerce is genuinely in scope, it belongs in a commerce platform.

Translation is the one to look at carefully rather than assume. CoreMedia documents deriving a translated site, finding content items that need translation, and comparing translations. Payload handles localisation per field and reads a locale on every query. The mechanism differs enough that a multi-site, multi-language estate should have this mapped during discovery.

What the migration involves

Discovery starts with an inventory: every content type in the deployed Blueprint model, every site and locale, the page grid variants in real use, the workflows in force, the rights rules, and the integrations. That inventory is the estimate, and a date given before it exists carries no information.

The build then runs in a familiar order. The content model is written as Payload collections in TypeScript and reviewed as code. The chosen extraction route supplies content and assets, and a transformation step converts rich text, maps folders and rebuilds relationships. A Payload and Next.js implementation then serves the front end through Payload’s APIs. Redirects are built from the old URL set before the front end is finished, with a legacy identifier kept on every document so the map survives a change to the model.

The checks at the end are the ordinary ones and they are not optional: metadata, canonical tags, sitemaps, structured data, and Core Web Vitals measured against the legacy site rather than against a target.

How we approach this

WAYF is an official Payload partner and a top contributor, so we have an interest in this recommendation and would rather say so than have you infer it. We build content platforms and CMS migrations on Payload and Next.js, and we work across a German estate with the hreflang infrastructure that goes with it.

Payload is a maintained open-source core under an MIT licence that you can host yourself, with no vendor holding your hosting contract or your data. Where an estate’s commerce, community or personalization requirements make CoreMedia the better answer, that is the answer we give.

The first step is a scoping conversation against your deployed content model. Book a call and we will go through the inventory above with you.

Sources

• CoreMedia Headless Server Developer Manual, CMCC 13
• CoreMedia Headless Server, endpoints
• CoreMedia Headless Server, content schema
• CoreMedia Content Server, XML export and its limitations
• CoreMedia Studio User Manual, publication workflows
• CoreMedia Studio User Manual, versions
• CoreMedia Studio User Manual, permissions and rights
• CoreMedia Studio User Manual, production and live environments
• CoreMedia Studio User Manual, content items and folders
• CoreMedia online documentation
• CoreMedia imprint
• Payload CMS documentation
• Payload CMS, versions and drafts
• Payload CMS, access control
• Payload CMS, blocks field
• Payload CMS, folders
• Payload enterprise publishing workflows
• WAYF on Payload’s partner directory

FAQ

1. How do you get content out of CoreMedia?

   One route uses the CoreMedia Headless Server: GraphQL at /graphql, GraphiQL at /graphiql in preview mode, and separate REST media downloads. It reaches the content exposed by the deployed schema. CoreMedia also documents cm serverexport for XML exports from the repository; it exports only the latest content version and omits metadata such as publication status. Choose and validate the route against the migration inventory.

2. Does the CoreMedia headless export cover the whole content model?

   No. The developer manual states that the schema file content-schema.graphql defines a subset of the CoreMedia Blueprint content model, with Blueprint content types mapped to GraphQL interfaces of the same name. Anything a project added to the document model over the years reaches the export only if the schema was extended to cover it, so the deployed schema has to be read against the deployed content model during discovery.

3. Can Payload reproduce CoreMedia's four-eyes publication?

   CoreMedia documents a Reviewed Publication workflow in which one editor starts the workflow and a second editor approves the publication. Payload licenses publishing workflows as an enterprise feature with no published price list. The alternative is to build the approval gate on the open-source core's drafts, versions and access control, which keeps the rule in the same repository as the rest of the code. Price whichever route applies before the build starts.

4. What happens to version history?

   Payload can retain and compare new document versions once versioning is enabled. Existing CoreMedia history needs a separate retention plan: the standard cm serverexport utility exports only the latest version, and a headless content export is not a historical archive. Agree whether old revisions and approval evidence must be extracted and mapped or retained in a readable archive, then test that requirement before decommissioning CoreMedia.

5. What does not move from CoreMedia to Payload?

   CoreMedia's production-to-live publication transfer is not reproduced by Payload's standard drafts model. Elastic Social histories, moderation and profiles need a retention or replacement plan. Commerce features such as category hierarchies, shoppable video and LiveContext connections need commerce-specific implementation. Localised content can be mapped, but translation workflows and the approval rules of each site need separate verification.