What you can and cannot take out of Contentstack before the contract ends
A renewal, a plan change or an exit decision means the content in your Contentstack stack has to leave the platform, and the Contentstack CLI is the starting point for that work. It exports the content structure and content in a documented form, but it leaves behind users, roles, releases and some version history, so an export is a starting point and not a complete backup. The sources supplied for this page do not cover Contentstack's own export formats, module names or size limits, so every Contentstack-specific detail below must be checked against the current Contentstack CLI documentation and a test export of a stack you can afford to lose.
Start by listing what your stack actually holds: content types and global fields, entries across each locale, assets and their folders, environments, publishing rules, extensions, webhooks, and workflow and role definitions. For each item, record whether the CLI export covers it, whether it arrives as data or only as a description, and who will rebuild it if it does not. Ask Contentstack in writing which module export order it expects, because dependencies such as content types before entries and assets before the entries that reference them determine whether a re-import succeeds. Keep the export log, because it is the only record of what the tool skipped.
Plan for the gaps before the contract ends, not after. Users, roles and permissions must be recreated in the new platform, so export your role matrix from the admin console while you still have access. Ask the vendor how many versions of each entry and asset the export keeps, and whether any non-latest history or past releases can be retrieved, since the answer decides whether you need a separate archive of published pages. Test branch-based or environment-specific content separately, and rename or deduplicate assets that could collide on filename before import. Do not delete the stack until a test import has produced the same entry counts, asset counts and rendered pages you expect, and until the vendor confirms in writing that your data is no longer needed for the exit.
Which Contentstack data types export, by method and format
This table lists each Contentstack data type, the method that moves it out of the stack, and the format and limits to verify. Most cells name the exact question to confirm in the Contentstack CLI docs, because the output details for each module are not yet verified here. Treat every open cell as a task to close before the contract ends and before the stack is deleted.
| Data type | Export method | Format and limits |
|---|---|---|
| Content types | CLI export module, confirm the module name and run order | Confirm the file format and whether schemas export before entries |
| Global fields | CLI export module, confirm it runs before content types | Confirm whether global fields export as a separate file or inside content types |
| Entries | CLI entries module, confirm how locales are selected | Confirm whether only the latest version exports and whether drafts are included |
| Assets (metadata) | CLI assets module, confirm whether folders and tags export | Confirm whether asset names can collide and how duplicates are renamed |
| Asset files | Confirm whether the CLI downloads binaries or only asset metadata | Confirm any size caps, retries or failure logs for large or failed downloads |
| Environments | Confirm whether environment settings export with the stack | Confirm whether publishing targets must be recreated by hand in the new CMS |
| Locales | CLI locales module, confirm it exports codes and fallback chains | Confirm whether fallback settings appear in the output and in which format |
| Branches | Confirm whether branch export is a separate command or flag | Confirm whether only the default branch exports and how branch content is merged |
| Users and releases | Confirm in the Contentstack CLI docs whether either exports | Plan to recreate roles and releases manually unless the docs confirm otherwise |
What the export leaves behind and how to recover each item
A Contentstack export carries content, but several operational records stay behind in the platform. Each card below names one of those gaps, the workaround a team can use, and who should own the work before the contract ends and the stack is deleted.
User accounts and their assignments
The export does not carry user accounts, so editors, reviewers and administrators are not in the data you move. Before the stack is closed, export a manual inventory from the settings screens: names, email addresses, roles and which people own which content types. Use that list to provision the new CMS. If you plan to use single sign-on for administrators, confirm how identities map in the target, as in Strapi SSO docs. Owner: platform administrator with HR or identity team.
Roles and permissions
Role definitions, field-level restrictions and environment rules are not part of the content export, so the access model must be rebuilt. Capture each role's permissions with dated screenshots or a spreadsheet covering stack, environment, content type and action. Map each row to a rule in the target CMS, such as Strapi roles or Payload field-level access control, and test with a user from each role. Owner: content operations lead, reviewed by security.
Releases and scheduled publishing
Releases are bundles of entries scheduled to publish together, and they do not come across in the export. List every open and past release, its date, and the entries it contains. Export those entries as ordinary content, then rebuild any future publishing schedule in the target system or in the release tooling you adopt. Remove scheduled jobs from the old stack so nothing publishes after cutover. Owner: content operations, with the engineer who runs publishing.
Older entry and asset versions
The export keeps only the latest version of each entry and asset. If auditors, legal teams or editors need earlier wording or files, run a script against the Content Management API before deletion and store the version history as JSON with the asset files alongside it. Record which entries and assets have version history and how long your retention policy requires keeping it. Owner: records or compliance lead, with an engineer to write the script.
Content held in branches
Work in progress on a branch may not be included in a standard export. Before export, list every branch, its owner and its status, and decide whether each one should be merged, published, discarded or exported separately. Confirm in the current Contentstack CLI documentation how branch content is exported in your version, then run a separate export for each branch you keep. Owner: content lead, who can confirm which branch work is still active.
Contentstack export sequence with verification at each step
This sequence takes a Contentstack stack from inventory to a checksummed archive that you can verify before anything is deleted. Each step names the output it produces and the check that shows it is complete. Confirm each CLI command and module name against the Contentstack documentation for your CLI version before you run it.
Inventory environments, locales and branches
The platform owner lists every environment, locale and branch in the stack, then records the content type, entry and asset counts for each one from the Contentstack dashboard. The output is a written inventory that serves as the reference for every later check. The step is complete when the counts in the inventory match the dashboard for each environment and locale, and when every branch you need to keep is named in the list.
Export each module in documented order
The developer confirms the module order in the current Contentstack CLI documentation and runs the export for each module in that order. Modules that depend on others, such as entries that reference content types, need their dependencies exported first. The output is one export folder per module with JSON files. The step is complete when every module folder exists, each JSON file parses, and the record counts the CLI reports match the inventory.
Download and store assets separately
The developer confirms in the CLI documentation whether the asset export downloads binary files or only metadata for your version, then runs the asset download into its own folder. Asset names can collide when files are stored under their original names, so keep a mapping file from asset UID to stored filename. The step is complete when the number of files and the total size match the asset count in the inventory, and any missing files are listed in an exceptions file.
Record users, roles and releases manually
Users, roles and releases are not part of the standard content export, so confirm this for your CLI version and record them by hand. An administrator documents each user's email, role and permissions, then each release with its name, scheduled date and included entries, using dashboard screens or exports where available. The output is a dated document in the archive. The step is complete when the record count for users and releases matches the dashboard.
Compare exported data with the live stack
The developer compares entry counts for each content type and locale in the export against the live stack, then samples entries across every content type and follows their references to confirm the target entries and assets exist in the export. Only the latest entry and asset versions are exported, so the team also records that version history is not in the archive. The step is complete when counts match, all sampled references resolve, and any gaps are logged with an owner.
Store archive with checksum and retention note
The developer generates a SHA-256 checksum for the full archive, writes a manifest that lists each module, the inventory and the record of users and releases, and stores both in at least two locations under the client's control. A retention note states who owns the archive, where it is kept and how long it must be retained under the client's policies. The step is complete when the checksum verifies on a copy, and a test restore into a scratch environment succeeds before the stack is deleted.
Why module order and reference checks decide whether the export is usable
A Contentstack export can finish without errors and still be unusable. Entries point to content types, global fields, assets and other entries, and each of those links depends on its target being in the archive. If a module is missing or is restored out of sequence, the entry keeps its reference but the target does not exist. The gap stays hidden until something re-imports the archive, which is usually after the contract has ended and the stack is no longer available to fix. Illustrative example: a blog post that references an author entry, where the author content type was exported after the post or not at all. The export log may show success, yet the import fails or leaves an empty field. Confirm the module order your CLI version uses against its current documentation before you rely on a single run.
The check to run is a sample test of references. Choose entries that carry links, starting with those that use global fields, nested references and multi-level relations, and include entries in every locale you publish. For each sampled entry, confirm that every target (its content type, global field, asset file and referenced entry) exists in the archive under the same identifier. Log the entry UID and any missing target so the failure can be traced. Pay particular attention to assets, because asset name collisions can point a reference at the wrong file when two files share a name. Also confirm that the archive holds the versions your editors expect, since only the latest entry and asset versions are carried over.
The same check is the first test of any future import into a self-hosted CMS. Strapi and Payload both need relations to resolve before content can be trusted, and an import script that meets a missing target will either fail or create orphaned relations. Run the sample before the stack is deleted, keep the archive and the check log together, and repeat the same sample against a staging import. Ask whether your internal team or implementation partner will own the mapping of references, and confirm with Contentstack whether a deleted stack can be restored, because that answer determines how much you can rely on the archive alone.
How the export changes for a single-branch stack and a multi-branch stack
When only one branch carries live work, the export is a single pass over the main stack. Run the export in the module order the CLI documents, then confirm the output contains the content types, entries and assets you expect before you rely on it. The export carries only the latest version of each entry and asset, so the file reflects the current state of the stack. Plan separately for the items the export does not include, whatever the branch count.
- One pass, one target: Run the full export against the stack's main branch and keep the output in a versioned location the team can restore from.
- Module order matters: Export content types before entries and assets so references can be rebuilt on import. Confirm the order against the current CLI documentation.
- Latest versions only: Earlier entry and asset versions are not carried over, so save a copy of any version history you need for audit before the export.
- Users, roles and releases stay behind: Record these from the admin console, because they do not appear in the export file.
Check that the entry and asset totals in the export file match what the stack reports before you schedule the deletion.
A stack that uses several branches for parallel work holds more than one set of content and schema that the export must account for. Each branch needs its own export, and the team must decide for each one whether its unmerged changes move into the main branch, get exported as a standalone archive, or are retired. Content that exists only on a feature branch is not in the main export, so it can disappear at contract end if nobody captures it.
- One export per branch: Run the export against every branch that holds content or schema you want to keep, and label each output with the branch name and date.
- Unmerged content is outside the main file: Entries and schema changes that exist only on a feature branch do not appear in a main-branch export.
- Decide per branch: For each branch, choose to merge it before export, export it as an archive, or retire it with sign-off from the content owner.
- Schema drift between branches: Two branches may define the same content type differently, so compare schemas before you map them to the new CMS model.
- Record the decision: Keep a register with the branch name, owner, decision and the file that holds its export.
Confirm with each content owner that no unreviewed work remains on a branch before you mark it retired.
Asset files are saved to local storage by file name during download. When two assets share a name, the second file can overwrite the first, while the export still lists both asset records. The problem usually surfaces after import as an image that is the wrong file or a file count lower than the asset count. Find collisions before the export starts, so you can rename or record them while the source is still available.
- How it happens: Two assets uploaded at different times or into different folders with the same file name can share one local path during download.
- Symptom after import: An entry points to the wrong image, or the number of files on disk is lower than the number of asset records.
- Check before export: List every asset with its name and identifier, sort by name and flag duplicates. Confirm the listing method in current Contentstack documentation or with support.
- Fix at source: Rename duplicates in the stack with clear, unique names and keep a mapping from old name to new name, or download each asset into its own folder.
- Verify after download: Compare the number of downloaded files with the asset list, and spot-check renamed items against the originals.
Do not delete the stack until the asset count and file count match, or every gap has a recorded reason.
What to plan before the Contentstack renewal or termination date
The export is the easy part to start and the hardest part to finish on time. Six planning items decide whether the archive is complete, whether the team can still reach the stack, and whether the deletion step is safe. Confirm the contract terms and deletion behavior with Contentstack before setting any date.
Notice period and plan terms
Read the signed order form and master agreement for the notice period, the renewal date and any auto-renewal clause. Note which plan you hold (Free, Build, Growth or Enterprise) and which add-ons, extra users or data-center choices are bundled. Ask Contentstack in writing how much time you have to export after termination and whether read access continues during that window. Work backward from the last day you can give notice, not from the day the subscription ends.
Date the archive must be complete
Set a fixed date by which a full export, asset download and checksum check are finished and stored outside the stack. Include time for a second export run, because content editors keep changing entries until the cutover. Decide whether the archive is a point-in-time snapshot or whether a final delta export runs just before the stack is frozen. Store the archive where the new platform and your retention policy can reach it.
Access needed for the export
The CLI needs a management token or user login with rights to read every content type, environment, locale and asset in the stack. Identify who holds the stack owner and admin roles, because they control API keys, roles and the deletion step. Confirm that the admin is reachable during the export window and that the person who runs the CLI can see all branches your team uses. Remove shared or departed-employee credentials before the export starts.
Target platform and hosting decision
Choose the replacement platform and where it will run before the export, since the target determines how you map content types, locales and assets. Compare Strapi, which needs PostgreSQL, MySQL, MariaDB or SQLite and a supported Node.js LTS, with Payload, which runs inside a Next.js app and supports MongoDB, PostgreSQL or SQLite. Decide which cloud account, region and team will host the database, object storage and CDN. Record this decision in writing so the migration team builds against one target.
Parallel run timeline
Plan a period where the existing Contentstack delivery and the new platform both serve content, so you can compare responses, check previews and confirm that editors can publish. Agree on how long this runs and who signs off on the cutover. Note that Contentstack features such as workflows, releases and roles are not carried over by the export, so editors may need to recreate them during this period. Freeze content changes on the old stack only after the sign-off is recorded.
Deletion step that ends the stack
Deleting the stack is irreversible for your data, so treat it as the final gate, not a cleanup task. Before running it, confirm that frontends no longer call the old delivery tokens, that webhooks are disabled, and that the archive has been opened and verified on a second machine. Ask Contentstack what is deleted, how long backups are retained after deletion, and whether a deletion certificate or written confirmation is provided. Keep the signed confirmation with your records for compliance review.
Questions buyers ask before they export their Contentstack data
How much effort does a Contentstack export take?
Effort depends mainly on the size and shape of the stack, and the export itself is often the smallest part of the work. The main drivers are the number of content types and entries, the number of locales, the number of branches that hold content you need, the volume of assets, and how many entries reference other entries or assets. Each locale and branch is a separate set of content to map and verify, and heavy reference chains take longer to rebuild in the target system. Have your team count these items before agreeing on scope, and write the counts down. A small stack with one locale and no branches is a short job, while a large multi-locale stack with many branches and references is a staged project.
Can our own team run the Contentstack export without outside help?
Yes, a team with the right access can run the export itself if someone understands both the content model and the CLI. The export is only the first step. Teams often stumble on what the export leaves behind: the standard export carries only the latest entry and asset versions, and it does not carry users, roles or releases. Asset name collisions and branch handling also need decisions before the copy is trusted. Internal teams often find the export straightforward and the verification and rebuild demanding. Decide early whether your people have time for both. An implementation partner can take on the export, the inventory of gaps and the verification under a written scope, while your team reviews and signs off.
What does the Contentstack export need from our team?
The work needs three roles filled before it starts:
- An admin on the Contentstack stack with rights to view users, roles, environments and branches, so you can record what the export will not carry.
- A developer comfortable with the Contentstack CLI and a terminal, who can run commands, store output securely and handle failures.
- A named owner who signs off the inventory, the list of gaps and the final verification.
Also agree who holds the exported files, where they are stored and who can open them. Exports contain production content and may include editorial and personal data, so access should follow your existing data handling rules.
How long does a Contentstack export take to complete?
Duration depends on your stack, so confirm it with a test run before you commit to a date. The clock is set by the stack size, the number of locales and branches, the asset volume and download speed, the number of gaps you must rebuild by hand, and how many review cycles the content owners need. Run a test export on a single branch or a copy of the stack first, time it, and then plan the remaining modules and branches from that measurement. Plan for verification and rebuild stages too, since these often take longer than the export. Ask for milestones tied to each stage in the written scope.
What should we ask Contentstack for in writing before we export?
Ask Contentstack to confirm in writing the points that decide whether your copy is complete:
- Which modules the export includes, the order it runs them in, and whether it keeps only the latest entry and asset versions for your stack.
- How branches are exported and whether each branch needs its own run.
- Whether users, roles, releases, workflows, webhooks and environment settings are carried over, and what happens to them.
- How long your access lasts after the contract ends, and when stored data is deleted.
- Whether any API call, bandwidth or storage charges apply to the export during your contract period.
Keep the answers with the contract file, and treat any answer that is not in writing as unconfirmed.
Can a Contentstack export replace a proper backup?
No, an export is a portable copy of content, and it leaves out elements a backup would keep. It carries only the latest versions of entries and assets and does not capture the full platform state, so you could not restore your Contentstack stack from it. Treat the export as one artifact in a retention plan. Store the files in storage you control, record checksums and the time of each run, keep access logs, and write a retention schedule. Test that the files can be read by loading them into the target system. Do not delete the stack until the copy has been verified and the business owner has accepted what the export does not carry.
What does a consultant take on in a Contentstack export engagement?
DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with the scope, deliverables and timelines agreed in writing before work starts. For an export, that scope can cover the inventory of stack contents, running the export by module and branch, recording what the export leaves behind, handling asset name collisions, checking the copy against the source, and documenting the evidence your team needs. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares records for compliance assessments but does not issue audit reports or certifications.
Which checks should we run before deleting the Contentstack stack?
Run these checks and get written sign-off before any deletion:
- Compare entry counts for each content type and locale between the stack and the export.
- Open sample entries in every locale and confirm that references resolve.
- Download a sample of assets, confirm they open, and check the outcome of any file name collisions.
- Confirm that every branch you need was exported and that each one was checked separately.
- Save records of users, roles, releases, webhooks and environment settings.
- Store the export with checksums and a retention schedule that you control.
The named owner should approve the results. Once the stack is deleted, the copy you hold becomes the only source for that content.
How DeployOpen scopes and delivers a Contentstack export and exit
DeployOpen treats a Contentstack export as a fixed-scope piece of work that starts with an inventory of what the CLI will and will not carry out of your stack. We then build, verify and document the export so your team holds a complete, checked copy of the content before the contract ends.
How we scope
- Inventory every content type, global field, environment, locale, branch and asset folder in the stack before any export runs.
- Record which items the CLI leaves behind, such as users, roles, releases and older versions, and assign an owner for each gap.
- Agree the scope, deliverables and timeline in writing before work begins, with the export checks named in the document.
How we build
- Run the export in the module order your stack needs, then compare exported counts against the live stack for each module.
- Detect asset name collisions and missing binaries, and script the fixes or re-downloads needed to keep the copy complete.
- Test that exported JSON can be read by the target self-hosted platform on a staging copy, not only archived.
How we hand over
- Deliver the exported archives, checksums, a reconciliation report and a written list of what was not carried over.
- Document the export runbook so your team can repeat it, including the steps to run before the stack is deleted.
- Walk your engineers and content owners through the handover and confirm the copy is held in storage you control.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- Support can cover re-running the export for a later branch or environment if your team finds a gap.
- Confirm the retainer terms, response expectations and scope of follow-up work in the written agreement.
