remove 2i steps (#197)

Author: aimurphy

modules/sideloader/pages/migrate-sideloader.adoc

@@ -179,35 +179,7 @@ nodetool listsnapshots
 +
 Snapshots have a specific directory structure, such as `*KEYSPACE_NAME*/*TABLE_NAME*/snapshots/*SNAPSHOT_NAME*/...`.
 {sstable-sideloader} relies on this fixed structure to properly interpret the SSTable components.
-**With the exception of secondary index directories (as explained in the following step), don't modify the snapshot's directory structure.**
-
-. If your origin cluster has xref:dse-5.1@cql:develop:indexing/2i/2i-concepts.adoc[secondary indexes (2i)], remove all directories related to those indexes from all snapshots before you xref:sideloader:migrate-sideloader.adoc#upload-snapshots-to-migration-directory[upload the snapshots].
-+
-[WARNING]
-====
-Secondary indexes defined in the origin cluster are ignored by {astra-db}, but they will cause the migration to fail.
-To avoid errors, you must remove all secondary index directories from your snapshots before you upload them.
-====
-+
-You can find secondary index directories in the table's snapshot directory:
-+
-[source,plaintext,subs="+quotes"]
-----
-**NODE_UUID**/**KEYSPACE_NAME**/**TABLE_NAME**-**TABLE_UUID**/snapshots/**SNAPSHOT_NAME**/.**INDEX_NAME**
-----
-+
-For example, given the following table schema, the index directory is found at `*NODE_UUID*/smart_home/sensor_readings-*TABLE_UUID*/snapshots/*SNAPSHOT_NAME*/.roomidx`:
-+
-[source,cql]
-----
-CREATE TABLE IF NOT EXISTS smart_home.sensor_readings (
-    device_id UUID,
-    room_id UUID,
-    reading_type TEXT,
-    PRIMARY KEY ((device_id))
-);
-CREATE INDEX IF NOT EXISTS roomidx ON smart_home.sensor_readings(room_id);
-----
+**Don't modify the snapshot's directory structure; this can cause your migration to fail.**
 
 [#record-schema]
 == Configure the target database

modules/sideloader/pages/prepare-sideloader.adoc

@@ -169,7 +169,7 @@ If you choose the alternative option, you must modify the commands accordingly f
 If you have a mix of encrypted and unencrypted data, you can use {sstable-sideloader} to migrate the unencrypted data.
 After the initial migration, you can use another strategy to move the encrypted data, such as https://github.com/datastax/cassandra-data-migrator[{cass-short} Data Migrator (CDM)] or a manual export and reupload.
 
-* *{sstable-sideloader} doesn't support secondary indexes*: If you don't remove or replace these in your origin cluster, then you must manually remove these directories from your snapshots, as explained in xref:sideloader:migrate-sideloader.adoc#create-snapshots[Create snapshots].
+* *{sstable-sideloader} doesn't support secondary indexes*: If you don't remove or replace these in your origin cluster, {sstable-sideloader} ignores these directories when importing the data to your {astra-db} database.
 
 == Administration server requirements
 

modules/sideloader/pages/troubleshoot-sideloader.adoc

@@ -38,7 +38,7 @@ The two most common errors are as follows:
 To resolve this error, you can <<relaunch,align the schemas and relaunch the migration>>.
 
 * *Invalid data in migration directory*: The data uploaded to the migration directory is invalid or improperly formatted.
-Common causes include data corruption, incomplete upload due to a timeout, malformed file paths, and the presence of invalid data such as secondary index directories.
+Common causes include data corruption, incomplete upload due to a timeout, malformed file paths, and the presence of invalid data.
 +
 When this type of failure occurs, you must abandon the failed migration and restart the entire migration process.
 For more information, see <<restart>>.
@@ -79,7 +79,7 @@ When a migration fails due to a problem with the data uploaded to the migration
 This is because you can't change the data in the migration directory after you upload it.
 For example, if your snapshots contain corrupt data, you have to restart the migration with new snapshots and a new migration directory.
 
-. Review the xref:sideloader:prepare-sideloader.adoc#origin-cluster-requirements[origin cluster requirements] to ensure that your snapshot doesn't contain invalid data, including materialized views, encrypted data, and secondary indexes.
+. Review the xref:sideloader:prepare-sideloader.adoc#origin-cluster-requirements[origin cluster requirements] to ensure that your snapshot doesn't contain invalid data, including materialized views and encrypted data.
 
 . If necessary, xref:sideloader:migrate-sideloader.adoc#create-snapshots[create new snapshots] of any invalid snapshots.
 +