Migrate from Contentful to Wagtail

How to migrate from Contentful to Wagtail without losing the content model

A renewal notice, a data residency requirement or a lock-in concern is usually what starts this move, and the work itself has two parts: translating the Contentful content model into Wagtail page models and StreamField blocks, then importing entries and assets and rebuilding the frontend. The content model is the part that decides whether the migration succeeds, because Contentful's content types, references and locales do not map one to one onto Django models. Most teams do this work with an in-house Python or platform team, sometimes supported by an outside implementation partner for the import scripts or the frontend. Effort and risk depend mainly on how many content types Contentful holds, how heavily entries reference each other, and how much of the delivery layer is hardwired to Contentful's API. Wagtail itself is BSD-3-Clause licensed and free for open and closed-source use, so the recurring license cost is zero, and the costs that remain are hosting, database, media storage, maintenance and any support contract you choose to buy.

Plan for the export to carry content, not the whole operating setup. The Contentful CLI space export captures the published content model, entries, assets, locales, webhooks and editor interfaces as JSON, and can download asset files, but roles and permissions are not included. Webhook credentials, memberships and any UI extensions must be recreated by hand, and the Wagtail equivalents (page permissions, groups and workflows) are a design decision, not an import. Confirm with your own export whether draft and archived entries come across, how embargoed assets are handled and whether every locale is present, since those gaps only surface after cutover. Ask any partner to show a mapping document listing each Contentful content type, its Wagtail page model or snippet, and the fields that need manual transformation, especially rich text and entry links that must become Wagtail page references. Redirect planning belongs in the same plan as the model translation. Contentful-hosted URLs, slugs and preview links will change once pages are served by Wagtail, so build a table of live URLs mapped to new paths and load it into Wagtail's redirect handling before the frontend switches. Test the mapping against real traffic logs rather than a sitemap alone, and keep the Contentful space readable until redirects and content checks pass. Confirm with Torchbox or your chosen partner which Wagtail release line you will target, since the current LTS line and its support dates should be checked on the Wagtail release schedule before you commit.

Which Contentful features move to Wagtail cleanly

This table maps each Contentful feature to its closest Wagtail equivalent and labels it clean, needs rework or gap. Read the status column first, then the notes, to see where schema and editorial work will land. The main takeaway is that content structure and assets move well, while roles, webhooks and preview need deliberate rebuilding in Wagtail's admin and deployment.

Contentful feature	Wagtail equivalent	Status	What to confirm or rebuild
Content types	Page models and snippets in Python	Needs rework	Each content type becomes a model. Confirm which types are pages and which are reusable snippets.
Entries	Page and snippet instances	Clean	Entries import by script into the page tree. Confirm parent pages and slugs before import.
Rich text fields	RichTextField or StreamField rich text block	Needs rework	Contentful's structured rich text needs conversion into Wagtail's rich text format. Test embedded entries.
References and links	ForeignKey, ParentalKey or page chooser fields	Needs rework	Map entry links to page IDs. Broken references usually surface only during content QA.
Assets (images and files)	Wagtail image and document library	Clean	Download files with the export. Confirm focal points and alt text, which may need manual entry.
Locales	Wagtail multi-language support with locale-aware pages	Needs rework	Confirm locale codes and fallback rules. Translated page trees must be created explicitly.
Webhooks	Custom signals, scripts or your own build hooks	Gap	The export carries webhook definitions, but not credentials. Rebuild triggers for frontend rebuilds.
Roles and permissions	Wagtail groups, collection permissions and workflows	Gap	Roles are not exported from Contentful. Confirm how Wagtail groups, workflows and moderation cover each editor role.
Editor interfaces and preview	StreamField blocks, panels and page preview	Needs rework	Editor layout is rebuilt in Python panels. Confirm whether live preview matches your editors' expectations.
Delivery API	Wagtail headless API or Django templates	Needs rework	Frontend queries and response shapes change. Plan the new endpoints before cutover.

How content types become Wagtail page models and StreamField blocks

The first decision is which Contentful content types become Wagtail page models. A page model is the right home for anything that has its own URL and sits in the site tree, such as a landing page, article or product detail page. Wagtail's tree is ordered and hierarchical, so the team should decide the parent-child structure and URL slugs at the same time. For illustrative purposes, a content type named articleLanding with child article entries would become a page model with a parent index page and a route pattern that matches the public URLs. Content types that never render on their own, such as a navigation item, a footer link set or a product category, usually belong in snippets or plain reusable models, which Wagtail can manage in its own admin area without creating routes.

Modular content fields are the second decision. A Contentful rich text field, or a references field holding a list of hero, quote and call-to-action entries, maps naturally to a StreamField with one block type per recurring component. Each block becomes a Python class with typed fields, so a heading block and an image block carry different validation rules. Rich text that editors write freely should stay a rich text block rather than being split into dozens of tiny blocks. Before writing blocks, pull a sample of entries and count how often each combination of components appears, because a block that only one editor uses in one place rarely justifies its own type. Entry-to-entry references need the same care. A reference that points to a page becomes a ForeignKey or a PageChooserBlock, a reference to a snippet becomes a ForeignKey to that model, and a reference to a shared component may become a block inside the stream. Any reference cycle in the export should be checked before import, because Wagtail will not resolve it automatically.

The inventory is the step most teams skip, and it should come first. Ask editors which entries they create, which fields they fill in, which they copy from other entries and which they never touch. Compare that with the export's content types and their editor interfaces, which the Contentful CLI space export includes as JSON. Dead content types, duplicated types with near-identical fields and fields that are empty in most entries are common findings, and each one changes the model design. Record the decisions in a mapping table that lists each Contentful type, its Wagtail target, its URL behavior and its owner. That table becomes the contract for the import scripts and for the redirect plan that follows.

What the Contentful space export gives you and what you rebuild

The Contentful CLI space export is the starting point for every Wagtail migration, but it carries only part of the space. The cards below separate what arrives as JSON and files from what you must recreate in Wagtail, so you can scope the rebuild before any content moves.

Content model, entries and editor interfaces

The space export writes the published content model, content types, entries, locales and editor interfaces as JSON. This is the input for your Wagtail page models and StreamField block definitions, but the JSON does not give you Wagtail code. Someone must read each content type and decide whether it becomes a page model, a snippet or a StreamField block. Confirm with the Contentful documentation whether draft content is included in your export before you plan the cutover, because unpublished editorial work may need a separate pass.

Asset files and metadata

The export can download asset files, not only the asset records that point to them. Check that every file downloaded, including any assets gated behind access controls, before you retire the Contentful space. In Wagtail, assets become images and documents with their own models, so titles, alt text, tags and focal points must be mapped during import. Plan a reconciliation count of asset records against files on disk.

Locales

Locales arrive in the export as definitions, but Wagtail handles multi-language content through its own locale and translation model, so each Contentful locale must be mapped to a Wagtail locale. Fallback chains in Contentful do not transfer automatically, and you must decide how untranslated pages behave on the new site. Test each language path with real editorial content before cutover.

Webhooks, rebuilt against new endpoints

The export carries webhook definitions, but the URLs and signing details point at Contentful-era consumers. Each webhook that triggers a build, a cache purge or a notification must be rebuilt against the endpoints your Wagtail site exposes, such as a publish hook or a frontend rebuild call. Remove any webhook that only fed a service you are retiring, and document which system now owns each trigger.

Roles and permissions, rebuilt as Wagtail groups

Roles and permissions are not included in the Contentful export. You rebuild them in Wagtail as groups with page permissions, collection permissions and workflow stages, which is a design task rather than an import. Inventory who edits, who approves and who publishes in Contentful today, then map those duties to Wagtail moderation workflows. Access rights to unpublished content need explicit review because the export does not carry them.

Frontend and API consumers

Frontends, mobile apps and other services call Contentful's delivery API with specific space IDs, tokens and query shapes. Wagtail exposes its own headless content API, so every consumer needs a new endpoint, new authentication and response fields that match the new page models. Inventory each consumer from your access logs and API keys before cutover, and confirm which ones can change their queries.

Migration sequence from inventory to decommission

This sequence moves a Contentful space into Wagtail in controlled stages, so each stage produces evidence that the next one depends on. Contentful stays the source of truth until editors and frontend consumers have signed off on Wagtail, and only then is it switched off.

Inventory content types and consumers
List every Contentful content type, its fields, locales, references and editor interfaces, then record every system that reads from the space, including websites, apps, search indexes, webhooks and scheduled jobs. Assign an owner to each consumer and note which ones depend on Contentful's delivery API response shape. The output is an inventory register with one row per content type and one row per consumer, reviewed by the content owners and the frontend team.
Pilot one content type and its frontend
Choose a single content type with a representative mix of fields, such as a rich text article with images and a reference, and model it as a Wagtail page model with a StreamField where blocks are needed. Build the matching frontend route through Wagtail templates or the headless API, then load a small sample of entries by hand. The output is a working pilot page that editors can create, preview and publish in Wagtail, plus a list of gaps in the model that the team still needs to resolve.
Build the schema and import scripts
Turn the export JSON from the Contentful CLI into the full set of Wagtail page models, snippets and image or document fields, based on the inventory and the pilot. Write import scripts that read the exported entries, assets and locales, map Contentful references to Wagtail page links, and download asset files from the export. Each run should write an import log that records every entry, its target page, skipped items and errors. The output is a repeatable import with a log that a reviewer can check against the source export.
Validate the import against the source
Compare the import log and the Wagtail database with the Contentful export entry by entry, covering counts, required fields, rich text rendering, locale fallbacks and asset file integrity. Ask a sample of editors to check their own content in Wagtail, including scheduled publishing and workflow states that the export does not carry over. The output is a validated import log with each discrepancy either fixed or accepted in writing by the content owner.
Run Wagtail and Contentful in parallel
Serve the new frontend from Wagtail while Contentful remains the editing source for live content, and compare rendered pages and API responses from both systems for the same URLs. Repeat the import for content changed in Contentful during this period, or agree a freeze window for editors. The output is a parallel-run comparison report listing every route, the differences found and the decision taken for each one.
Cut over and redirect traffic
Apply the redirect plan from the URL inventory so that old Contentful-driven URLs resolve to the matching Wagtail pages, then switch editing and publishing to Wagtail and update webhooks, search indexing and scheduled jobs. Confirm that the frontend, analytics and monitoring see the new routes. The output is a cutover record with the switch date, the redirect test results and the sign-off from the editors and the owners of each consumer.
Decommission Contentful after a final export
Once Wagtail has run as the editing system through an agreed observation period, take a final Contentful export and store it with the other records under your retention policy. Revoke API keys, remove webhooks and team memberships, and confirm with the contract owner what happens to the space at expiry. The output is an archived export, a decommission checklist signed by the owner, and written confirmation that no consumer still reads from Contentful.

How the migration changes by team skills and starting point

A team that already writes Django will find Wagtail's model-first approach familiar. Content types usually become page models, which are Django classes that subclass Wagtail's page model and declare fields and StreamField blocks. Schema work is therefore a code review exercise: each Contentful content type is mapped to a page model or a snippet, and each rich text or modular field is mapped to a StreamField block definition. The import tooling is typically a custom management command or script that reads the space export JSON and creates pages through Wagtail's Python API. The frontend build is the Django template layer, so most of the rendering work stays in the same repository.

Page model mapping: Decide which content types are full pages with URLs and which are reusable snippets, since this choice drives the tree structure.
StreamField blocks: Translate Contentful's embedded entries and rich text into typed blocks, and decide early how references to other entries become page or snippet links.
Import scripts: Write idempotent import commands that can be rerun against a staging database without duplicating pages.
Template rendering: Port existing component templates into Django templates, which removes a separate build step for the frontend.
Team ownership: Editors gain direct control of page structure, so agree on who may add block types before the schema is frozen.

Confirm the current Django compatibility and StreamField API details in the Wagtail documentation, since the supported Django versions change with each release.

What drives the cost and duration of a Contentful to Wagtail move

This table lists the factors that change the effort and running cost of moving a Contentful space to Wagtail, with the reason each one matters and how to keep it contained. Read it before requesting a scoped quote, because the same driver often appears in several cost lines. Most of the variable effort sits in content modeling, the frontend rebuild and the team's Django skills, not in the raw export.

Driver	Why it adds effort or cost	How to keep it down
Content types and reference chains	Each content type becomes a Wagtail page model or snippet, and deep reference chains require entries to be created in dependency order during import.	Audit the export's content model first, merge near-duplicate types, and flatten references that only exist for layout.
Rich text and embedded entries	Contentful rich text and embedded entries must be converted into StreamField blocks or Wagtail rich text links, which needs a custom mapping for each embed type.	Limit the number of embed types, and agree on a small block library before scripting the import.
Number of locales	Each locale multiplies translated entries, slugs and URL structures, and Wagtail locale trees must be configured per site.	Confirm which locales are live and which are retired, and migrate only the active set in the first pass.
Asset volume and file size	Assets must be downloaded from the export and re-uploaded to Wagtail's image or document models, and storage grows with every rendition.	Remove unused assets before export and decide early on the storage backend and image rendition policy.
Embargoed or restricted assets	Assets behind access controls may not download with a standard export, so each one may need a separate retrieval path.	Confirm with the Contentful account owner which assets are restricted and how their files will be fetched.
Frontend consumers and webhooks	Every app, site or service that reads Contentful content or receives its webhooks must be repointed to Wagtail's API or templates and retested.	Inventory consumers and webhook targets before scoping, and retire unused ones instead of porting them.
Editorial workflow complexity	Contentful roles and workflows are not part of the export, so approval chains, permissions and scheduled publishing must be rebuilt with Wagtail's workflows and moderation.	Document the current approval steps and map them to a small number of Wagtail workflow stages.
Frontend rebuild	If the current frontend reads Contentful's delivery API directly, its data fetching, rendering and caching must be rewritten against Wagtail's API or templates.	Decide whether to serve Wagtail templates or a separate frontend, and reuse existing components where the data shape stays stable.
Redirects and URL structure	Changed slugs and paths break search rankings and links, so each URL must be mapped and tested.	Export the current URL list from analytics and logs, and build the redirect table alongside the page models.
Team Django experience	Wagtail runs on Django, so a team without Python or Django skills needs training or outside help, which adds staff time or consulting fees.	Assess skills before choosing the build approach, and ask a partner to pair with internal developers during the first model build.
Recurring hosting, database and storage	Servers or containers, a PostgreSQL database, media storage, search and backups recur every month, and they are paid to a cloud provider or data center.	Size the database and media storage from the export, and ask the provider for a cost breakdown per component.
Upgrades and security support	Wagtail releases a feature version every three months and publishes LTS releases with security support, so upgrades are a recurring staff or partner task.	Plan to run an LTS line and schedule upgrades, and confirm with your team which release line you will track.
One-time migration work	Content modeling, scripted import, validation, the frontend build, redirects and cutover are one-time costs paid to staff, a partner or both.	Ask for a written scope listing each deliverable, and request a fixed price for each phase.

What usually goes wrong in a Contentful to Wagtail migration

Most failed content migrations fail quietly: entries import without errors, but links break, assets vanish, or editors discover missing workflows after launch. The cards below cover the failure modes that recur in Contentful to Wagtail moves and the checks that catch each one before cutover.

Lossy rich text conversion

Contentful rich text is a structured document tree, and Wagtail's StreamField blocks are typed fields, so a direct copy often flattens embedded entries, tables or custom marks. Map each Contentful node type to a named block or a rich text field before importing. Then run a validation script that counts embedded entries and links in the export and in Wagtail, and sample-review a set of pages per content type for dropped elements.

Broken references after import

Contentful entries reference each other by ID, and those links must become Wagtail page foreign keys or page chooser values. Import in dependency order, keep a mapping table from Contentful entry IDs to Wagtail page IDs, and fail the run when a reference cannot be resolved. A reconciliation report listing unresolved references per content type gives editors and developers one place to start.

Assets missing from the export

The Contentful CLI can download asset files, but assets that are embargoed or restricted may not download without access. Compare the asset count in the export JSON with the number of files actually saved, and list every failed download with its asset ID. Re-check each failure against the space's access settings before you treat the asset as lost, and confirm that Wagtail image and document records point to the stored files.

Editors losing preview and workflow habits

Editors who relied on Contentful's entry states, scheduled publishing and preview links will not find the same behavior in Wagtail by default. Wagtail provides content workflows, moderation and revisions, so define the approval path and draft states with the editorial team before cutover. Run a short walkthrough with real editors using a staging copy and record which habits need training or custom configuration.

Roles rebuilt incorrectly

The space export does not carry roles and permissions, so access rules must be rebuilt by hand in Wagtail's groups and page permissions. Write down each Contentful role, the spaces and content types it covered, and the Wagtail group that replaces it. Have the content owner sign off on the matrix and test each group with a sample account to confirm that it can edit, publish or see only what it should.

Old webhooks and integrations still running

Webhooks are exported with the space, but they point at endpoints that may still trigger builds or syndication from the old space. Inventory every webhook and downstream consumer, then disable or repoint them in the same change window as the content cutover. Confirm that no pipeline still calls the Contentful delivery API, and keep the old space read-only until the new site has run cleanly for an agreed period.

Frontend caching serving stale content

A frontend that caches Contentful responses, or a CDN in front of the old site, can keep serving old pages after the new Wagtail content is live. Set a cache invalidation step into the cutover checklist, purge CDN and frontend caches for migrated paths, and compare sample URLs from the old and new sites after the switch. Keep the redirect map in place so that cached old URLs resolve to the correct new pages.

Redirect planning and running both systems in parallel

Start redirect planning before any content moves, because the URL map is the one artifact that decides whether search rankings and inbound links survive the switch. Export the list of live Contentful-driven paths from your analytics, server logs and sitemap, then map each one to a Wagtail page path. Where a Contentful content type previously produced URLs from a slug field, decide whether the Wagtail page model keeps the same slug and parent structure or whether the path changes. Record every mapping in a version-controlled CSV or spreadsheet with the old path, new path, status code and owner. Wagtail's redirects module can hold these rules, and the redirect table is easiest to test when it is loaded from that same file. Test the mappings against a staging copy of the Wagtail site by crawling the old URL list and confirming each request returns a single 301 to the correct final page, with no chains or loops.

Run both systems in parallel with a clear rule for where editors work. The safest default is to make Contentful read-only once the import has been validated, and to re-run the export and import for any entries changed after the first pass, using the same identifiers so Wagtail pages are updated rather than duplicated. If editors must keep publishing in Contentful during a longer window, schedule a repeatable sync job and agree who is allowed to edit in each system on each day. Confirm with your Contentful plan whether scheduled publishing and webhooks are still active during the freeze, since a webhook pointing at a decommissioned frontend can fail silently.

At cutover, check four things in order. First, confirm that Wagtail's search index is populated for every page that replaces an old URL: Wagtail's integrated search works with Elasticsearch or PostgreSQL, so confirm with your platform team which backend fits your hosting before you build the index job. Second, publish a new XML sitemap that lists only the new canonical URLs and submit it to search consoles. Third, purge or expire CDN and reverse proxy caches so that stale Contentful responses are not served, and confirm that the Wagtail frontend sends correct cache headers. Fourth, verify scheduled publishing: content with future publish dates must exist in Wagtail with the same go-live times, and you should confirm that Wagtail's publishing workflow runs as a scheduled task on your own servers.

Questions buyers ask before a Contentful to Wagtail migration

What does a Contentful to Wagtail migration cost?

The cost depends on the size and shape of the content model, the number of locales, the volume of assets and how much frontend work comes with the move. Wagtail itself carries no license fee because it is BSD-3-Clause, so the spend is labor, hosting, search infrastructure and any support contract you choose. Mapping content types to page models and StreamField blocks is usually the largest one-time item, followed by frontend porting and redirect work. Ask any implementation partner for a quote built from a written scope that lists content types, locales, asset counts, integrations and the frontend to be rebuilt. Recurring costs are hosting, database and media storage, a CDN if you use one, and upgrades. Compare those lines against your current Contentful subscription and usage charges, using your own usage data.

How long does a Contentful to Wagtail migration take?

The timeline is set by scope, not by the export itself. Schema translation, importing entries and assets, rebuilding templates or API consumers, and testing redirects each take time, and editor training and content review often run in parallel. The biggest drivers are the number of content types, how much rich text and reference logic must be converted into StreamField blocks, the number of locales and the frontend rebuild. Ask for a phased plan with milestones, a parallel run period and a cutover window in the written scope. Confirm the timeline against a pilot import of one representative content type before committing to dates.

Can our own team run this migration without outside help?

A team with Python and Django experience can do the work in-house, provided it has time, someone who owns the content model and a plan for testing. Contentful's CLI space export gives you content types, entries, assets, locales and editor interfaces as JSON, but it does not export roles or permissions, so those must be rebuilt by hand in Wagtail. Teams without Django depth, or with a tight deadline, often bring in a partner for the schema mapping, import scripts and cutover. DeployOpen plans, implements and hardens self-hosted platforms in your own infrastructure under fixed-scope agreements, and can provide that help if you want it. Either way, define who owns each deliverable before work starts.

What do editors and developers have to do during the move?

Editors must review how their content now fits Wagtail page models and StreamField blocks, because some layouts and reference patterns will change shape. Developers define page models, block types, snippets and image renditions in code, write import scripts that read the export JSON, and rebuild the frontend, either with Wagtail templates or by consuming the headless content API. Editors also need training on the Wagtail admin, including page trees, drafts and moderation. Plan a content freeze or a delta sync before cutover so changes made in Contentful after the export are not lost. Confirm with your editorial lead how many people will test content on staging and how long that review will take.

Do roles, workflows and approvals carry over from Contentful?

Content itself carries over, but access control does not come across automatically. The Contentful CLI export does not include roles or permissions, so you must design the Wagtail groups and permissions yourself. Wagtail does provide content workflows and moderation, so approval steps can be recreated, but they will be configured in Wagtail rather than copied from Contentful. Document each existing Contentful role, the actions it allows and the people in it, then map those to Wagtail groups and workflow stages. Confirm with your security team how access reviews and audit logging will work in the new environment before go-live.

Is Wagtail free to run, and what does the BSD-3-Clause license allow?

Yes, Wagtail is licensed under BSD-3-Clause and is free for open and closed-source use, so you do not pay a license fee to run it or to build proprietary sites on it. The license does not cover your hosting, database, search, storage or staff time. Wagtail also offers commercial support and hosting through Torchbox, its primary sponsor, which is optional. Review the license text with your legal team and check the repository for any third-party packages or plugins you add, since each may carry its own terms.

How do Wagtail's release cadence and LTS support affect maintenance?

Wagtail ships a feature release every three months, and an LTS release typically arrives once every four feature releases with eighteen months of support. Wagtail 7.4 LTS, released May 4, 2026, has security support until November 2, 2027, and Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028. Choose an LTS line for production, plan an upgrade window for each support end date, and confirm Django compatibility, since Wagtail supports Django 5.2.x, 6.0.x and 6.1.x. Budget recurring upgrade effort in your run plan, and confirm with the release schedule before fixing your upgrade calendar.

How DeployOpen scopes, runs and supports a Wagtail migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Contentful to Wagtail, that means the Wagtail site, its database, media storage and frontend delivery run where your security team already controls access and evidence.

How we scope

Inventory every Contentful content type, locale, webhook and asset rule before estimating page model work
Agree in writing which content types map to page models, snippets and StreamField blocks
Define redirect coverage, frontend delivery approach and cutover criteria as part of the fixed scope

How we build

Build Wagtail page models and StreamField blocks from the agreed content model in version control
Script entry, asset and locale import from the Contentful space export, then reconcile counts against the source
Test the editorial workflow, multi-language routing and the API or template frontend before cutover

How we hand over

Document the page model design, import scripts, redirect map and environment configuration for your team
Deliver backup and restore procedures for the Wagtail database and media store, with a tested restore
Record access roles, workflow settings and the evidence your auditors will ask to see

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Plan Wagtail upgrades against the published release schedule, including LTS support windows
Confirm with us in the written scope which support hours, response terms and upgrade cadence apply