Content migration is different for every organization, yet the principle is always the same. You want to get data from one system to another.With all the headless benefits, you may undergo your last content migration right now. But since that joy alone won’t help you get it done, this course will guide you through the main steps of every content migration using the Kontent.ai CLI.
The building blocks of content migration
Whenever you want to migrate your content, you need to deal with three things:
Source – defines the data you want to migrate. For example, this can be content in an old CMS, CRM, spreadsheet, or even in a CSV file.
Destination – defines where you want to put the source data. This is Kontent.ai.
Adapter – transforms and maps the data between the source and the destination, and imports it to the destination. This is what Kontent.ai CLI helps with.
Explore the CLI migration samples
In the video, Jake Kula, our Presales Engineer, shows you how to use the migrations boilerplate for Kontent.ai CLI to run a series of content migrations.This approach works well for content migrations within an existing Kontent.ai project as well as for importing content from external resources such as databases, other CMSs, spreadsheets, or CSV files.You can also use the same approach to import and export content for your backups.The boilerplate comes with migration scripts built around the example of making a content model change and updating the affected content items. You’ll see Jake go through these steps:
Perform content migration to extract the names of article authors, create a content item for each name, and link the content item in respective articles.
Once you know how to work with the CLI and how to run the migration scripts, you can adjust the existing scripts. Depending on the amount of content you need to migrate, decide whether you want to hardcode specific values in your scripts or get the values dynamically from the source of the migration.In the next lesson, you’ll go over our best practices for content migrations so that you can be confident your migrations won't affect your production environment.
What's next?
Safe content migrations in production
Performing content migrations directly in production can be risky. To mitigate that risk, we recommend you clone your production environment, make your changes in the clone, validate and test, and swap the two environments. This approach works well for both small and complex changes.
Why not just one script that handles it all?It's a good practice to have one migration script per task. That way you know better where to look when something fails.
