Importing Data into Headless Content Management Systems

This blog post describes techniques that you can use to import data into a headless Content Management System (CMS).

Regardless of the tools used to import, the content needs to be in a format defined by the CMS vendor, typically JSON. Some CMS vendors manage rich text as JSON or another format, which may require conversion before or during import.

All techniques for importing data into headless content management systems depend on the underlying content management HTTPS service endpoints exposed by the CMS vendor.

• You can use user interfaces provided by the CMS vendor that import content.
• You can use scripts or other tools provided by the CMS vendor that import content.
• You can use an SDK from the vendor that provides native APIs that wrap the content management service endpoints to implement custom processes that import content.
• You can call the content management service endpoints directly from the technology of your choice to implement custom processes that import content.

There are three types of data that you may need to import, generally in the following order:

• Content type definitions
• Media assets including metadata and binary content
• Text that may reference media assets and may depend on updated content types

Content types define the fields that make up types of content entries. Entries store text values for the fields defined in a content type. Media entries contain metadata and reference binary media such as images, generally by URL path relative to the root of a Content Delivery Network provided by the CMS vendor. The order of import is important because media asset entries may depend on updated content type definitions and imported text may reference imported media.

It may be necessary to import content and types of content in specific orders or update references afterwards because any imported content entry can contain references to other imported content entries. For example, if a recipe entry references ingredients entries, it may be necessary to import ingredients before importing recipes so that recipes can store CMS identifiers for ingredients. It may be necessary to import content types, media, and content entries in one or more batches before other content types.

Something may need to remove or alter styles, JavaScript, and other attributes of imported HTML, as well as updating references to the URLs of pages, media, and anything else that changes after migration. In general, content migration is an opportunity for content and information architecture review.

For cases where the CMS identifier of a referenced item cannot be determined when importing a referencing entry, such as when importing content that references other content not yet imported, the import process can store custom identifiers rather than CMS identifiers, and a subsequent process can update those temporary references.

You can extend the CMS user interface to make data from an external application appear in the CMS and to store data from external systems, such as references, in the CMS. For example, a dashboard extension present information from an external analytics system, while a product selector could provide a custom field type for use in entries.

Importing data depends on vendor-specific access credentials.

If you know more about importing content into headless CMS systems, please comment on this blog post.