diff --git a/core/modules/migrate/migrate.api.php b/core/modules/migrate/migrate.api.php
index c705d17..664df62 100644
--- a/core/modules/migrate/migrate.api.php
+++ b/core/modules/migrate/migrate.api.php
@@ -27,12 +27,9 @@
  * data source. The data can be migrated from a database, loaded from a file
  * (for example CSV, JSON or XML) or fetched from a web service (for example RSS
  * or REST). The row is sent to the process phase where it is transformed as
- * needed or marked to be skipped. Processing can also determine if a 'stub'
- * needs to be created. For example, if a term has a parent term which hasn't
- * been migrated yet, a stub term is created so that the parent relation can be
- * established, and the stub is updated at a later point. After processing, the
- * transformed row is passed to the destination phase where it is loaded (saved)
- * into the target Drupal site.
+ * needed or marked to be skipped. After processing, the transformed row is
+ * passed to the destination phase where it is loaded (saved) into the target
+ * Drupal site.
  *
  * Migrate API uses the Drupal plugin system for many different purposes. Most
  * importantly, the overall ETL process is defined as a migration plugin and the
@@ -82,6 +79,39 @@
  *
  * @link https://api.drupal.org/api/drupal/namespace/Drupal!migrate!Plugin!migrate!destination List of destination plugins for Drupal configuration and content entities provided by the core Migrate module. @endlink
  *
+ * @section sec_key_concepts Migrate API key concepts
+ * @subsection sec_stubs Stubs
+ * Taxonomy terms are an example of a data structure where an entity can have a
+ * reference to a parent. When a term is being migrated, it is possible that its
+ * parent term has not yet been migrated. Migrate API addresses this 'chicken or
+ * the egg' dilemma by creating a stub term for the parent so that the child
+ * term can establish a reference to it. When the parent term is eventually
+ * being migrated, Migrate API updates the previously created stub with the
+ * actual content.
+ *
+ * @subsection sec_map_tables Map tables
+ * Once a migrated row is saved and the destination ID is known, Migrate API
+ * saves the source ID, destination ID and the row hash into a map table. The
+ * source ID and the hash in the map allow for tracking changes for continuous
+ * migrations. Other migrations can use the map tables for lookup purposes when
+ * establishing relations between records.
+ *
+ * @subsection sec_highwater_marks Highwater marks
+ * Highwater marks allow Migrate API to track changes so that we can migrate
+ * only content that has been created or updated in the source since the
+ * migration was previously executed. This requires the source to have a special
+ * highwater property. This can be any property that indicates the highest value
+ * migrated so far. If the source system has for example a timestamp that
+ * indicates when a node was created or last updated, that timestamp could be
+ * used as a highwater property. If we execute the migration again, only those
+ * nodes that have a higher timestamp than in the previous migration would be
+ * included.
+ *
+ * @subsection sec_rollbacks Rollbacks
+ * It is quite typical that when developing a migration, the first version does
+ * not provide correct results for all scenarios. Rollbacks allow you to undo a
+ * migration, adjust the migration and then execute it again.
+ *
  * @section sec_more_info Documentation handbooks
  * @link https://www.drupal.org/docs/8/api/migrate-api Migrate API handbook. @endlink
  * @link https://www.drupal.org/docs/8/upgrade Upgrading to Drupal 8 handbook. @endlink