Merge pull request #53811 from sbeskin-redhat/MTC_openshift-docs_issues_49638

Issue 49638: Removing duplicate text

Author: bscott-rh

modules/migration-state-migration-cli.adoc

@@ -13,7 +13,7 @@ State migration is specifically designed to be used in conjunction with external
 
 If you have a CI/CD pipeline, you can migrate stateless components by deploying them on the target cluster. Then you can migrate stateful components by using {mtc-short}.
 
-You can perform a state migration between clusters or within the same cluster. 
+You can perform a state migration between clusters or within the same cluster.
 
 [IMPORTANT]
 ====
@@ -27,42 +27,6 @@ State migration migrates only the components that constitute an application's st
 * The manifests of the application are available in a central repository that is accessible from both the source and the target clusters.
 
 
-.Procedure
-
-. Migrate persistent volume data from the source to the target cluster.
-+
-You can perform this step as many times as needed. The source application continues running.
-
-. Quiesce the source application.
-+
-You can do this by setting the replicas of workload resources to `0`, either directly on the source cluster or by updating the manifests in GitHub and re-syncing the Argo CD application.
-
-. Clone application manifests to the target cluster.
-+
-You can use Argo CD to clone the application manifests to the target cluster.
-
-. Migrate the remaining volume data from the source to the target cluster.
-+
-Migrate any new data created by the application during the state migration process by performing a final data migration.
-
-. If the cloned application is in a quiesced state, unquiesce it.
-
-. Switch the DNS record to the target cluster to re-direct user traffic to the migrated application.
-
-[NOTE]
-====
-{mtc-short} 1.6 cannot quiesce applications automatically when performing state migration. It can only migrate PV data. Therefore, you must use your CD mechanisms for quiescing or unquiescing applications.
-
-{mtc-short} 1.7 introduces explicit Stage and Cutover flows. You can use staging to perform initial data transfers as many times as needed. Then you can perform a cutover, in which the source applications are quiesced automatically.
-====
-
-.Prerequisites
-
-* The state of the application on the source cluster is persisted in `PersistentVolumes` provisioned through `PersistentVolumeClaims`.
-
-* The manifests of the application are available in a central repository that is accessible from both the source and the target clusters.
-
-
 .Procedure
 
 . Migrate persistent volume data from the source to the target cluster.