Contentful to WordPress Migration: Preserve Linked Content, Locales and Publishing Needs
A practical guide for teams deciding whether to replace a marketing frontend, the content source or both when moving from Contentful.
In this article
Illustrative workspace. Screens show concepts, not a delivered client system.
A Contentful space can support a marketing website, an app and other publishing channels. Moving the website to WordPress is therefore not always the same as moving the entire content platform. Before commissioning a Contentful to WordPress migration, identify what will change and which consumers still depend on the existing content.
The Contentful to WordPress service focuses on assessing that boundary, mapping the relevant content and rebuilding the approved public-facing website. This guide helps a marketing or technical owner prepare a brief without losing the relationships that make the content useful.
Separate the frontend decision from the content-source decision
Choose whether WordPress becomes the marketing frontend, the publishing system or both. If an app continues to consume Contentful, retiring a shared space could affect more than the website. A selective move, a retained source or a wider transition may each be appropriate, depending on the actual architecture.
Create a consumer register: the website, other applications, scheduled jobs, search processes and services triggered at publication. Record their owners and the content they use. The WordPress scope should describe how each dependency will continue, change or be retired.
Understand the export and the remaining transformation work
Contentful’s CLI export documentation describes exporting a content model and content data, including entries, assets and locales. The resulting representation is not an Elementor website. Select the environment and content states intentionally, then plan how the exported fields and references become WordPress structures.
Keep source identifiers during transformation so related items can be matched reliably. Decide which drafts and archived entries are in scope instead of publishing every exported record. The team should approve content decisions before the import is expanded to production.
Map linked entries instead of duplicating them everywhere
A shared author, product or call-to-action entry may be referenced by several pages. If every relationship becomes copied text, future edits can drift. Decide whether the destination uses structured records, relationships or shared templates.
| Content relationship | Mapping question |
|---|---|
| Article to author | How will one author record support multiple articles? |
| Page to shared promotion | Which destination object owns the reusable content? |
| Rich text to embedded entry | How should the embedded item render and be edited? |
| Page to asset | Which media file and metadata belong to that reference? |
Include embedded content, nested references and intentionally missing records in the sample. A successful basic article import does not establish that a reference-heavy landing page will render correctly.
Keep locales and publishing behaviour in the brief
Record the locales actually used by the website, their field values and any fallback rules. Agree how WordPress will represent the variants and their URLs. Ask the content owners to review a translated sample rather than assuming one language check covers all output.
Publishing also has dependencies. Your current setup may notify a frontend, update search or trigger another process when an entry changes. Document those events and the expected replacement behaviour. An export of entries does not recreate every workflow, preview route or connected application.
Validate a representative model before the wider move
Choose a sample containing linked entries, rich text with an embedded object, an asset and a locale variation. Build the destination fields and rendering in staging. Review the content with an editor and the relationships with the technical owner.
- Compare record counts for the approved types and publication states.
- Check that references resolve to the intended records rather than accidental duplicates.
- Verify images, downloads, titles and important metadata.
- Test an ordinary editorial change and its agreed publishing effects.
Keep a list of unresolved references and source exceptions. This makes the wider migration easier to review and helps distinguish implementation work from content decisions that need an owner.
Scope URLs and a controlled release
Create a URL mapping from the existing frontend to the approved WordPress destinations. A content entry ID is not a public URL, so routing rules and slugs need their own review. Include important articles, campaign pages and downloads in the release checks.
Agree how the final content changes are captured, who controls the public switch and what recovery involves. If Contentful remains for other consumers, its ongoing responsibilities should stay documented. Use the WordPress migration overview to consider those shared stages.
Bring a content model to the quote discussion
A useful enquiry includes the website, spaces and environments in scope, a content-type summary, important relationships, locales and a consumer register. Add design references, editor requirements and your target launch window. Share descriptions of access requirements through the public form; arrange credentials separately.
The proposal can then separate mapping, frontend work, content transfer, integrations and release support. Review my portfolio for website examples, then request a Contentful migration scope discussion. I’ll assess the WordPress work against the actual content model and dependencies.
Written by
Jagjeet Singh
Full stack development, WordPress engineering and practical web products. I work with businesses, teams and agencies in India and worldwide.
Explore my work
