How to export your data from Contentful before the contract ends
A renewal, a price change, a data residency rule or a lock-in concern usually makes a complete export necessary, and the first thing to know is its scope. The Contentful CLI space export command takes the published content model, content, assets, locales, webhooks and editor interfaces out of a space as JSON, and it can download asset files as well. Roles and permissions do not come with it, so memberships, access rules and who can edit what must be recorded separately before the contract ends.
Treat the export as a starting point, not a finished copy. Webhook URLs come across, but the credentials and secrets behind them do not, so each integration must be re-keyed in the new system. UI extensions and custom editor code live in your own repositories and need to be rebuilt. Confirm with Contentful which spaces, environments and locales your plan covers, and check that the export includes unpublished drafts if your editors rely on them, since the documentation describes a published content model and content.
To verify the export, compare entry counts per content type against the Contentful web app, open a sample of entries in each locale, and confirm that every asset file downloads and matches its metadata. Keep the raw export archived with a checksum and a dated inventory of roles, webhooks and extensions. The Contentful CLI space export documentation is the next read for the exact flags and file layout your version produces.
Which Contentful data the export carries out
This table lists each data type the Contentful CLI space export carries out of a space, the method and format used, and what to confirm before relying on the output. Most rows reflect the documented export scope, while the tags row depends on the contentful-export library and should be verified in its current docs. The main takeaway is that the export covers the content model and content well, but roles and memberships must be rebuilt.
| Data type | Export method | Format | What to confirm |
|---|---|---|---|
| Content types | CLI space export | JSON | Export covers the published content model; confirm how unpublished changes are handled |
| Entries | CLI space export | JSON | Compare entry counts and linked references against the source space after export |
| Assets (records) | CLI space export | JSON | Asset metadata is written to JSON; confirm the fields and URLs included with Contentful |
| Asset files | CLI space export with asset download | Downloaded files | Confirm access to embargoed assets and any file size or rate limits with Contentful |
| Locales | CLI space export | JSON | Confirm all locales and fallback settings appear in the output |
| Webhooks | CLI space export | JSON | Definitions carry over; confirm whether any credentials or secrets are included |
| Editor interfaces | CLI space export | JSON | Layout configuration carries over; confirm what custom UI extensions require |
| Tags | contentful-export library | JSON | Listed as carried over; confirm exact output in the current library documentation |
| Roles and memberships | Not exported by the CLI space export | Not applicable | Recreate users, roles and permissions in the target system |
What the export leaves behind and how to rebuild it
The export gives you the content model, entries, assets and locales, but several controls live outside the space's JSON. Each card below names one of these gaps, the risk if it is missed, and how to rebuild it before you switch traffic to the new CMS.
Roles and permissions
The contentful-cli documentation states that roles and permissions are not exported. Your content types may import cleanly while every editor, reviewer and publisher loses the access rules they relied on. Before you export, open the space settings in the Contentful web app and record each role, its content type and locale restrictions, and which actions it may take, such as publishing or editing. Keep this record in a spreadsheet owned by your content operations lead. In the new platform, map each role to a Strapi or Payload role or access control function and test it with a non-admin account.
Space memberships
Memberships tie named people to the space and to its roles. The export does not carry them, so the new CMS starts with no users at all. Missing memberships are easy to overlook because the content itself looks complete. Export the membership list from the admin console as a record of who held access, marking each person as active, offboarded or contractor. Then decide which accounts need to exist in the new CMS and which should be dropped. Confirm the account lifecycle with your identity team, since the new CMS's admin login may run through a separate identity provider.
Webhook credentials
The export includes webhook definitions, meaning their names, target URLs and triggers, but not the secrets or tokens used to authenticate calls. A webhook that is copied without its credential will fail silently for downstream builds, search indexes or cache purges. Record each webhook target, its trigger events and the system that receives it. Then issue new secrets in the new platform, store them in your secrets manager, and rotate the old credentials on the receiving side once the cutover is verified. Treat the old Contentful tokens as compromised once they have been copied into a file.
Editor UI extensions
Editor interfaces in the export describe field layout, but the custom UI extensions that run inside the Contentful web app do not move with them. A field that editors use for a custom picker or validation may disappear from the editing screen, leaving authors unable to complete entries. List every extension bound to a content type, document what it does and who depends on it. In the new CMS, rebuild each one as a custom field component or a built-in field type with validation, and test it against a sample of real entries before editors switch over.
Embargoed assets
Assets that are not yet published or that sit behind restricted access can fail during a bulk download, leaving gaps in your media library. A missing file breaks image references in entries even when the JSON is complete. Compare the count of assets in the export with the count of downloaded files, and list any that failed. Retry the failed downloads with a token that has the required access, then store the files in your own object storage and update the URLs in the imported records.
Webhook and role audit trail
Change history and the record of who changed what usually stay in the source platform. Without a copy, you lose the ability to answer audit questions about past edits, approvals or publishing. Ask your compliance lead which history must be retained and for how long, then store an exported snapshot in your own archive. Confirm with your auditor whether a read-only copy of the old space satisfies the retention requirement before you close the subscription.
How to download embargoed assets without losing them
The Contentful CLI can download asset files as part of a space export, but a download is only as good as the credentials and URLs behind it. Embargoed or access-restricted assets need their own check because a request can fail when the asset is not reachable with the credentials the export runs under. A failed download does not stop the export from completing, so a backup that looks finished may still be missing files. Treat the asset list as a separate deliverable, not a side effect of the JSON export.
Before the contract ends, run the export against your space and compare the asset records in the output with the files actually written to disk. List every asset whose download fails, with its asset ID, title, locale and the content entries that reference it, so you can judge which content would break in a new system. Ask Contentful how embargoed and restricted asset URLs are signed, how long those signatures last, and whether a link that expires mid-export needs to be requested again. Keep the answers in writing, because the exact mechanism is the vendor's to define and may change.
Keep a dated record of every failure, the command and CLI version used, and the outcome of each retry, and store it with the export archive. DeployOpen verifies this in your own space during scoping, including which assets fail under your roles and credentials, and whether the failed set can be recovered from the source before access ends. Ask your team to confirm that nobody is about to remove a user or API key that the export depends on, since that is the most common reason an asset set becomes unrecoverable.
The sequence for a complete Contentful export
This sequence produces a verified, dated archive of a Contentful space that holds the content model, entries, assets and locales, plus a written record of the parts the CLI does not export, so nothing is lost when the space is retired.
Confirm the space ID and environment
The space administrator confirms the exact space ID, the environment alias you will export (for example, master) and the delivery and management tokens your team uses. Record them in the migration log with the date and the name of the person responsible. The step is done when a second person has read the space ID and environment back from the Contentful web app and matched them to the CLI configuration you plan to use.
Take an inventory of the space
Before running any export, list every content type, locale code, role, membership and webhook in the space, using the web app or the management API. Save the list as a spreadsheet or text file. The output is a baseline that the export will be checked against. It is done when you have a count of content types, a list of locale codes, and a list of webhook names and target URLs.
Run the CLI space export with assets
Run the Contentful CLI space export command against the confirmed space and environment, with the option that downloads asset files enabled. The CLI writes the published content model, entries, assets, locales, webhooks and editor interfaces as JSON, and the asset files as well when that option is set. Check the command documentation for the flags available in your CLI version. It is done when the command exits without errors and the output folder contains the JSON files and an asset directory.
Verify entry counts and locales against the source
Compare the number of entries for each content type in the export file with the counts from the Contentful web app, and check that every locale code in the export matches the locale list from your inventory. Also confirm that the number of assets in the JSON equals the number of files downloaded. Investigate any difference before continuing. The step is done when every count matches or each difference is documented with a reason, such as drafts that the published export does not include.
Store the archive with a checksum and dated copy
Compress the export folder into a single archive, generate a SHA-256 checksum for it and store the checksum in a separate file. Place the archive in two locations under your control, such as an encrypted object store and an offline or second-region copy, and name both with the export date and space ID. The step is done when the checksum is recomputed from one stored copy and matches the recorded value.
Export roles and memberships by hand
The CLI does not export roles, permissions or memberships, so record them from the Contentful web app or management API. For each user, note the role, the scope of access by content type or locale, and whether the account is still active. Keep personal data to the minimum your privacy policy allows. The step is done when every active member and role appears in a dated register that a reviewer has signed off.
Record webhook endpoints and credential owners
For each webhook in the inventory, record the target URL, the trigger events, the owning team and the person who holds the credentials that the receiving system uses. The export keeps the webhook definitions but not the secrets, so list where each secret is stored. Ask the owner to confirm the endpoint is still in use. The step is done when every webhook has a named owner and a confirmed status of active, retired or to be replaced.
List failed asset downloads and resolve them
Review the export log for assets that did not download, and check each one against the asset list in the JSON. Common causes include expired or restricted URLs, and assets that Contentful serves under access controls, so ask the space administrator to confirm which assets need a fresh download path. Retry the failed items, and keep a written list of any that remain unavailable with the reason. The step is done when the list is empty or every remaining item is recorded with an owner and a decision.
How to verify the export is complete
Treat the archive as unverified until you have compared it against the live space. Start with entry counts per content type: open the Contentful web app, record the number of entries for each content type, and match those figures against the counts in the exported JSON. Any gap points to entries that were unpublished, archived, or excluded during the run, and each one needs a named explanation. Then confirm that every locale your editors use appears in the export, including fallback locales, because a missing locale usually shows up as blank fields rather than as an error. Compare asset counts the same way, and download a sample of asset files with the --download-assets option so you can open them and confirm they are not truncated or zero bytes. Record the file sizes and checksums of the sampled files so the copy you keep can be checked later.
Next, confirm that the structural definitions made it into the JSON. Search the file for the webhook definitions and the editor interface entries, since the CLI carries these in the export, and compare the webhook list with what your team sees under the space settings. Note that the export covers published content only, so draft and changed-but-unpublished entries are not part of the archive. Decide, with your content owners, whether drafts must be captured, and ask Contentful in writing how its current CLI version handles drafts and archived entries before you treat the export as complete. Roles, memberships and webhook credentials are outside the export, so list them separately as items to rebuild.
Finally, sign off the checks in writing. Name one owner for the content verification and one for the technical checks, and have each record the counts, locales, sampled files and open exceptions in a dated document kept with the archive. Anyone who later finds a gap should be able to see what was checked and who accepted the result. This record also feeds the migration plan, because each exception becomes a task for the team that will rebuild the space in your self-hosted platform.
What to plan before the Contentful contract ends
The export itself is the easy part. The risk sits in the dates around it: when access ends, whether a restore has been tested, and who owns the parts the export does not carry. Work through these items in order, and keep the written terms from Contentful's account team at the center of the timeline.
Confirm the end date in writing
Ask Contentful's account team to confirm the contract end date, the notice terms and what happens to read access and stored assets after the term ends. Get the answers in writing and keep them with the project plan. Notice periods and fees are set in your agreement, so do not assume standard terms apply to your contract. Everything else in this plan depends on that date.
Schedule a test export and restore
Run the space export against a copy of the space well before the contract ends, then restore it into your target environment. Compare entry counts, locales and asset downloads with the source. A test restore shows gaps in content types, references and rich text while there is still time to fix them, and it gives you a real measure of how long the final export will take.
Keep read access until sign-off
Do not let read access lapse when the new system goes live. Keep the Contentful space readable until your team has verified the final export against the new CMS and signed off the migration. Note that roles and memberships are not part of the export, so the source space is also where you check who had what access before the switch.
Control where the archive lives
The export holds your content model, entries and downloaded asset files, and often editorial drafts and internal notes. Store it in an encrypted location you control, restrict access to named people, and record who copied it and when. Set a retention rule for the archive so it does not outlive its purpose, and confirm that your data protection obligations cover any copies held by partners.
Assign owners for roles and webhooks
Roles, memberships, webhook credentials and UI extensions do not come across in the export, so each needs a named owner after the switch. Assign someone to recreate editor permissions in the new CMS, rotate or reissue webhook secrets for build hooks and integrations, and review any hard-coded Contentful asset URLs in your front end. Track these as separate items so none are lost when the contract ends.
Questions buyers ask about exporting from Contentful
How much effort does a Contentful export take?
The export commands themselves are short, but the effort comes from the size and shape of the space. The CLI space export command writes the published content model, content and assets as JSON, and it can also download asset files. Effort rises with the number of locales, the volume of asset files, the number of content types and entries, and any custom UI extensions or webhooks that need to be recorded and rebuilt by hand. Roles and permissions are not exported, so anyone planning a move has to document access rules separately. Plan for a test export on a copy of the space first, then count the entries, locales and assets it produced. Those counts are the best input for scoping the rest of the work.
How long does a Contentful space export take?
No reliable duration can be given without measuring it in your own environment. The main factors are the number of entries and assets, the total size of asset files you choose to download, and how the export is run. Run a test export against a representative space, record how long the JSON export and the asset download each take, and extrapolate from there. Ask your team or a partner to report those numbers alongside the list of content types, locales and assets, so the timeline reflects your real content rather than a generic estimate.
Can our team export a Contentful space without outside help?
Yes, the export step itself is within reach of a technical team with admin access, since the CLI runs the export and writes the output to files. The harder part is what the export does not carry. Roles, memberships and permissions must be recorded by someone who understands your editorial workflow. Webhook endpoints usually depend on credentials that the export does not include, so they need an owner who can recreate and test them. Asset downloads can fail for individual files, so someone must check the failure list and retry or source the missing files. Assign a named owner for each of these areas before the export begins.
What does the export need from our team?
The team needs three things: administrative access to the source space and the ability to run the CLI with the right credentials, a named owner who signs off on what has been captured, and time for verification. Verification means comparing content types, entry counts, locales, tags and asset files against the source, and checking that webhooks and editor interfaces are documented even if they are not recreated automatically. Editors should review a sample of entries in each locale, since rich text and references often need spot checks. Ask your team to keep the exported JSON, the asset folder and the verification notes in a controlled location, because these become the reference for any later migration step.
Does exporting from Contentful complete a migration?
No. An export gives you a copy of the content and its model, but it does not build the target system. A self-hosted CMS needs its own content types or collections, field mappings, rich text and reference transformations, asset re-uploads, roles, webhooks and frontend integration. Each target CMS has a different data model, so the exported JSON must be translated, not simply imported. Treat the export as the first deliverable of a migration project, and plan the schema work, content transformation, testing and cutover as separate steps with their own owners and acceptance criteria.
What does a consultant add to a Contentful export?
A consultant can scope the export, define what is in and out of it, run the export under a documented procedure, verify the output against the source, and hand over the results with an inventory of gaps. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and prepares the evidence your team needs for internal reviews. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and any quote follows from that written scope. DeployOpen does not publish a price list. Ask any provider for a written list of the items each deliverable covers, the verification method, and the handover materials.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Contentful export, we start from a written scope that defines which spaces, environments, locales, assets and integrations must leave Contentful intact, then deliver the export, verification and handover as documented work.
How we scope
- Inventory every space, environment, locale and content type you need to carry out of Contentful
- Agree in writing which assets, including embargoed files, must be downloaded and how they will be verified
- Record what the export will not carry, such as memberships, webhook secrets and UI extensions, so owners can rebuild them
How we build
- Run the Contentful CLI space export against a copy of each space and keep the JSON in version-controlled storage
- Script asset downloads and check file counts and checksums against the source space before any import begins
- Test the exported content model against a sample import in your target platform to confirm field types and references map correctly
How we hand over
- Deliver the export archives, asset manifests, verification reports and a field-by-field gap list in a documented package
- Document the rebuild list for roles, permissions, webhooks and UI extensions with an owner and status for each item
- Walk your engineering and content teams through the package so they can repeat the export and check it themselves
How we support
- Keep the export tooling and runbook current for re-runs before cutover, which is useful when content keeps changing
- Offer ongoing support, upgrades and continuous testing for the platform that receives the content as a retainer
- Confirm with your team the retention period for Contentful exports and the access controls for archived content
