comment fixes

modules/ROOT/pages/index.adoc

@@ -9,68 +9,33 @@ A migration is a workflow that encompasses the lifecycle of uploading and import
 DataStax has developed a set of thoroughly tested self-service tools to walk you through well-defined migration options:
 
 * Zero Downtime Migration
-* Cassandra Data Migrations
-* DSBulk Migration
+* Cassandra Data Migrator
+* DSBulk Migrator
 
-First, a couple of key terms to understand for using our migration tools:
+With these tools, you can move your application to {astra_db}, DSE, or Cassandra with no downtime and with minimal configuration changes.
+Your clusters are kept in sync at all times by a dual-write logic configuration.
+You can roll back at any point, for complete peace of mind.
 
-* **Origin:** This cluster is your existing Cassandra-based environment, whether it's open-source Apache Cassandra, DSE, or {astra_db} Classic.
-
-* **Target:** This cluster is the new environment to which you want to migrate client applications and data.
-
-
-////
-[TIP]
-====
-An important migration prerequisite is that you already have the matching schema on Target. 
-A CQL statement that your client application sends to {zdm-proxy} must be able to succeed on both Origin and Target clusters. 
-This means that any keyspace that your client application uses must exist on both Origin and Target with the same name. 
-Table names must also match. For more, see xref:feasibility-checklists.adoc#_schemakeyspace_compatibility[Schema/keyspace compatibility].
-====
-
-Your migration project occurs through a sequence of phases. 
-Here is an example of these phases with ZDM using ZDM proxy, which is a simple and lightweight proxy that handles all the real-time requests generated by your client applications.
-For more, see http:addlinkhere.adoc[ZDM proxy]
-
-image::{imagesprefix}zdm-migration-all.png[Migration phases from start to finish]
-
-Before walking through illustrations of each phase, look at a pre-migration, high-level view. At this point, your client applications are performing read/write operations with an existing CQL-compatible database. That is, Apache Cassandra, DSE, or Astra DB.  
-
-image::{imagesprefix}zdm-migration-before-starting.png[Diagram shows existing CQL-compatible environment before migration starts.]
-
-Before any migration begins, complete prerequisites, prepare your environment, and set up the recommended infrastructure.
-////
-
-== Migrations with and without zero downtime examples
-
-Data migrations with downtime are those where the data being migrated is critical for ongoing operations, and the migration process itself requires systems to be taken offline temporarily. Downtime may be required for:
-
-* Migration for large-scale systems: these systems may require downtime for completely smooth transition.
-* Database migration: large database migrations or database software upgrades may need downtime for data consistency and integrity.
-* Storage system migration: migrating from on-prem to cloud may need downtime to reconfigure systems.
-* Network infrastructure changes: these systems may require downtime for completely smooth transition.
-
-A migration with no downtime is seamless and ideal, but doesn't always happen. This happens when your business can tolerate a brief outage. 
-Here are scenarios for such migration:
+== Migrations with and without zero downtime
 
+Data migrations with downtime are those where the data being migrated is critical for ongoing operations, and the migration process itself requires systems to be taken offline temporarily. 
+Your business determines the downtime for any migration and how much downtime (if any) is necessary. 
+Large amounts of data require more time; small amounts of data require less time and may also be migrated through the {astra_ui}.
 
 == Data migration tools
 
 For modest data volumes where temporary downtime is tolerable, Datastax recommends two open-source data migration tools to help with brief outages:
 
-* Cassandra Data Migrator: The best choice to migrate large data quantities, and where detailed logging, data verifications, table column renaming (if needed), and reconciliation options are provided.
-* DSBulk Migrator: This leverages DataStax Bulk Loader (DSBulk) to perform the data migration, and provides new commands specific to migrations. DSBulk Migrator is ideal for simple migration of smaller data quantities, and where data validation (other than post-migration row counts) is not necessary.
+* *Cassandra Data Migrator*: The best choice to migrate large data quantities, and where detailed logging, data verifications, table column renaming (if needed), and reconciliation options are provided.
+* *DSBulk Migrator*: This leverages DataStax Bulk Loader (DSBulk) to perform the data migration, and provides new commands specific to migrations. DSBulk Migrator is ideal for simple migration of smaller data quantities, and where data validation (other than post-migration row counts) is not necessary.
 
 These tools provide sophisticated features that help you migrate your data from any Cassandra Origin (Apache Cassandra®, {company} Enterprise (DSE), {company} {astra_db}) to any Cassandra Target (Apache Cassandra, DSE, {company} {astra_db}).
 
-== Zero downtime migration
-
-For large datasets, it's best to use the zero downtime migration tool: Zero Downtime Migration (ZDM).
+For large datasets, it's best to use the Zero Downtime Migration (ZDM).
 ZDM provides a simple and reliable way for you to migrate applications from any CQL-based cluster (Apache Cassandra®, {company} Enterprise (DSE), {astra_db}, or any type of CQL-based database) to any other CQL-based cluster, without any interruption of service to the client applications and data.
 
-* You can move your application to {astra_db}, DSE, or Cassandra with no downtime and with minimal configuration changes.
-* Your clusters will be kept in sync at all times by a dual-write logic configuration.
-* You can rollback at any point, for complete peace of mind.
+xref:components.adoc#role-of-zdm-proxy[ZDM proxy], the main component of ZDM, is an open-source software designed to run in a clustered fashion so there is never a single point of failure. 
+It handles all real-time requests generated by your client applications.