Can you leave your CMS? Test data export and portability before development

The best way to test CMS data portability is to create a trial export and use it outside the supplier's working environment. The export needs intelligible content, relationships between records, required files and metadata. Separately establish what is not transferred and what work will be needed to use the data in another system.

For a business owner, asking about leaving does not necessarily imply distrust. Teams, systems and business needs change. Before commissioning a custom CMS, it is useful to know whether the next maintainer can continue with the materials received. “You own the data” does not itself explain how to obtain and restore it.

Technical portability and contractual rights are related but separate questions. This article helps define a technical test. It does not replace legal assessment of a contract or licences, nor does it promise cost-free migration.

First define what the company wants to take with it

A content export, a system backup and a complete application handover are different outcomes. A content export may suit migration to another platform. A backup may be intended to restore the same system. Taking over an application may additionally require code, configuration, a runtime environment and documented deployment.

Before asking for a “full export”, write down its intended use. Do you want to restore the existing CMS on another server? Move content to another product? Change maintainers while keeping the system? Each scenario has different requirements, and one archive will not necessarily support them all.

Public WordPress documentation, for example, describes a WXR XML export containing specified content types and import into another WordPress site. WordPress export scope. This helps frame the right question for a custom CMS too: what does the particular tool include, rather than merely what is its button called?

State exclusions in the portability requirements as well. If the full history or a data block from an external system will not be included, that must be known in advance. An explicit limitation can be managed. An undisclosed one usually emerges when the old environment is about to be shut down.

Content can lose meaning without relationships

A product name and description do not reconstruct a catalogue. Its categories, variants, linked files and language relationships are also needed. If an export retains only human-readable values, the stable identities needed to reconnect these parts may be lost.

Check whether records have identifiers and whether references to them can be resolved. Matching names are not a reliable linking key. Export documentation needs a clear schema: which field points where, how an empty value is represented and how lists or repeated blocks should be interpreted.

Examine history and statuses separately. Current text is insufficient if you need to know what was previously published. If migration needs only the current version, the scope can deliberately be limited. Agree whether the export includes drafts, archived content, publication dates and approval history where the company relies on it.

Strapi documentation provides another export example: a defined archive containing content, relationships, files, schemas and configuration, with specified exclusions such as administrators and API tokens. Strapi export description. Another CMS will not automatically understand this format, but it illustrates why both contents and exclusions need to be documented.

A file URL is not the file itself

An exported table may contain links to images in the old supplier's storage. While that remains available, the test website looks complete. Once access closes, the images disappear. A portability test must therefore establish whether the required files themselves have been received and whether the new environment can use them independently.

Check original files as well as previews. PDF files, downloadable technical documents, captions and alternative text may be needed. Retain each asset's identity and its link to the relevant record. Identical filenames must not cause files to overwrite one another.

Contentful's export-tool documentation has a separate downloadAssets option for downloading files. Contentful export settings. This specific example shows why the settings used must be recorded. The tool's name alone does not prove that the export contains every required asset.

Ask for a file inventory and a way to check integrity. On receipt, counts and checksums can be compared, but that is not enough to establish content completeness. Check that the correct file is linked to the correct product and can be opened in a usable format.

What to retain about URLs and multilingual content

Current addresses, language links and metadata are useful during migration. If an address changes in the new system, a plan will be needed to map the old address to the new one. The aim here is not to predefine every SEO redirect decision, but to retain the information needed to make those decisions safely later.

Test a multilingual record with fields populated differently across languages. The export must distinguish a real translation, missing content and a fallback value. Otherwise, the new environment may accidentally publish source text as a completed translation.

The meaning of dates and statuses must also be documented. A technical update date may differ from the publication date. Merging both into one field can create an incorrect history. Trial records help identify these ambiguities before a full migration.

List licences and external dependencies separately

Receiving code does not automatically allow every paid component, image or external service to be transferred. List the licences used and establish whose account holds them. Specific transfer and continued-use rights must be checked in the relevant terms and contract.

An external dependency might be a search service, payment provider, email delivery service or image store. If its settings exist only in the supplier's account, exported content will not restore operation. Determine which dependencies can be reconfigured under the company's account and which need replacing.

Do not put secrets in an ordinary content archive. Use a separate secure process to hand over or replace API keys and passwords. In a test environment, use appropriately restricted access rather than automatically connecting production integrations. A portability test must not accidentally send customers messages or create real orders.

Knowledge of the runtime environment is also a dependency. If only one developer can start the system using settings stored on their computer, takeover has not been demonstrated. Clear instructions and a list of prerequisites are needed that another competent team can follow.

A trial export before signing the contract

Before commissioning the project, select a small but varied demonstration dataset. It might contain a standard record, multilingual content, related records, a file and a draft. Examples should cover complex relationships, not merely an attractive single-page description.

Ask the developer to demonstrate export creation and explain it. Then try restoration in a separate environment using the documentation that the next maintainer would receive. If the project has not yet been built, the demonstration can use a prototype, with a repeat test using project data specified in the contract.

The table is a proposed acceptance test, not a claim about any product's completeness. Each project must specify mandatory items and deliberate exclusions. Repeatability matters: another specialist must be able to understand what the test established.

Questions to ask the developer

Ask to see the export format and schema documentation. Establish who can create it, whether supplier involvement is needed and how data can be obtained when the regular working relationship ends. If export is a separate service, its scope and charging method need to be known early.

Ask how completeness is checked. Is there an object and file inventory? How does the tool report a failed download? Can a partial export appear successful? At completion, the company needs a clear result with exceptions, not merely a message saying the process has ended.

Ask separately about takeover instructions and external dependencies. Where is configuration that is absent from the export stored? Which access does the company manage itself? Which actions must remain disabled in the new environment until testing is complete? These answers help assess actual maintenance independence.

Finally, ask for technical feasibility to be distinguished from the amount of work involved. Data may be obtainable, but field structures, image links or content blocks may need transformation in the new CMS. That does not automatically make it a poor solution. The nature of that future work must be clear rather than hidden behind the word “export”.

What creates migration work later?

Costs are affected by differences in content structure, data quality, file volume and integrations. Complex content blocks understood only by one system may need transformation. Incomplete metadata or broken relationships require investigation rather than simple copying.

Changes between the trial export and the actual move must also be considered. If work continues in the old system, agree on the final dataset and its verification. Assess failure handling separately: when can work resume in the old environment, and how can divergent data changes in both places be prevented?

A portability test cannot eliminate all this work in advance. It can reveal the main limitations and support a clearer project brief. Assess it alongside everyday usability and maintenance, rather than treating it as the sole CMS selection criterion.

Does JSON or CSV mean the data is portable?

They are readable formats, but the format name does not establish whether meaning, relationships and files have been preserved. Check documentation and perform a practical import for the intended use. Without that, the file may be only a partial copy of the data.

Does an open-source CMS remove supplier dependence?

It may provide certain technical options, but custom extensions, licences, accounts and missing documentation can still complicate takeover. Assess the specific project and the actual handover test.

Put portability into the requirements while you still have a choice

Before commissioning development, define the intended exit scenario, mandatory export contents and restoration test. Retain the acceptance result and known exclusions. This gives a concrete basis for a later takeover discussion rather than a dispute about different interpretations of “full”.

For a custom CMS requirements assessment, include data export and future maintenance options. For project budget components, see custom CMS costs; for broader handover checks, see website acceptance testing.