MIG-1078 Updating MTC 1.7 Compatibility Guidelines.

_attributes/common-attributes.adoc

@@ -46,7 +46,7 @@ endif::[]
 :launch: image:app-launcher.png[title="Application Launcher"]
 :mtc-short: MTC
 :mtc-full: Migration Toolkit for Containers
-:mtc-version: 1.6
+:mtc-version: 1.7
 :mtc-legacy-version: 1.5
 :mtc-legacy-version-z: 1.5.3
 //gitops

modules/migration-compatibility-guidelines.adoc

@@ -5,21 +5,51 @@
 // * migration_toolkit_for_containers/installing-mtc.adoc
 // * migration_toolkit_for_containers/installing-mtc-restricted.adoc
 
+:_content-type: CONCEPT
 [id="migration-compatibility-guidelines_{context}"]
 = Compatibility guidelines
 
 You must install the {mtc-full} ({mtc-short}) Operator that is compatible with your {product-title} version.
 
-You cannot install {mtc-short} {mtc-version} on {product-title} 4.5, or earlier versions, because the custom resource definition API versions are incompatible.
+.Definitions
 
-You can migrate workloads from a source cluster with {mtc-short} {mtc-legacy-version-z} to a target cluster with {mtc-short} {mtc-version} as long as the `MigrationController` custom resource and the {mtc-short} web console are running on the target cluster.
+legacy platform:: {product-title} 4.5 and earlier.
+modern platform:: {product-title} 4.6 and later.
+legacy operator:: The {mtc-short} Operator designed for legacy platforms.
+modern operator:: The {mtc-short} Operator designed for modern platforms.
+control cluster:: The cluster that runs the {mtc-short} controller and GUI.
+remote cluster:: A source or destination cluster for a migration that runs Velero. The Control Cluster communicates with Remote clusters via the Velero API to drive migrations.
 
-[cols="1,1,2", options="header"]
-.{product-title} and {mtc-short} compatibility
+
+[cols="1,2,2", options="header"]
+.{mtc-short} compatibility: Migrating from a legacy platform
 |===
-|{product-title} version |{mtc-short} version |{mtc-full} Operator
+||{product-title} 4.5 or earlier |{product-title} 4.6 later
+|Latest {mtc-short} version a|{mtc-short} {mtc-version}.z
+
+Legacy {mtc-version} operator: Install manually with the `operator.yml` file.
+[IMPORTANT]
+====
+This cluster cannot be the control cluster.
+====
+
+|{mtc-short} {mtc-version}.z
+
+Install with OLM, release channel `release-v1.7`
+|Stable {mtc-short} version |{mtc-short} 1.5
 
-|4.5 and earlier |{mtc-legacy-version-z} |Legacy {mtc-full} Operator, installed manually with the `operator.yml` file.
+Legacy 1.5 operator: Install manually with the `operator.yml` file.
 
-|4.6 and later |Latest {mtc-version}.x z-stream release |{mtc-full} Operator, installed with Operator Lifecycle Manager.
+|{mtc-short} 1.6.z
+
+Install with OLM, release channel `release-v1.6`
 |===
+
+[NOTE]
+====
+Edge cases exist in which network restrictions prevent modern clusters from connecting to other clusters involved in the migration. For example, when migrating from an {product-title} 3.11 cluster on premises to a modern {product-title} cluster in the cloud, where the modern cluster cannot connect to the {product-title} 3.11 cluster.
+
+With {mtc-short} {mtc-version}, if one of the remote clusters is unable to communicate with the control cluster because of network restrictions, use the `crane tunnel-api` command.
+
+With the stable {mtc-short} release, although you should always designate the most modern cluster as the control cluster, in this specific case it is possible to designate the legacy cluster as the control cluster and push workloads to the remote cluster.
+====