diff --git a/site/content/docs/main/api-types/schedule.md b/site/content/docs/main/api-types/schedule.md
index e9afea460..5b96737c5 100644
--- a/site/content/docs/main/api-types/schedule.md
+++ b/site/content/docs/main/api-types/schedule.md
@@ -123,8 +123,6 @@ spec:
     ttl: 24h0m0s
     # whether pod volume file system backup should be used for all volumes by default.
     defaultVolumesToFsBackup: true
-    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
-    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     # Whether snapshot data should be moved. If set, data movement is launched after the snapshot is created.
     snapshotMoveData: true
     # The data mover to be used by the backup. If the value is "" or "velero", the built-in data mover will be used.
@@ -133,6 +131,8 @@ spec:
     uploaderConfig:
         # ParallelFilesUpload is the number of files parallel uploads to perform when using the uploader.
         parallelFilesUpload: 10
+    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
+    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     metadata:
       labels:
         labelname: somelabelvalue
diff --git a/site/content/docs/main/migration-case.md b/site/content/docs/main/migration-case.md
index daac425f4..fee41b1ea 100644
--- a/site/content/docs/main/migration-case.md
+++ b/site/content/docs/main/migration-case.md
@@ -102,3 +102,7 @@ Check that the Cluster 2 is behaving as expected:
     Your data that was backed up from Cluster 1 should now be available on Cluster 2.
 
 If you encounter issues, make sure that Velero is running in the same namespace in both clusters.
+
+
+## Notice
+If the two clusters couldn't share the snapshots generated by backup, for example migration from EKS to AKS, then please consider using [the file system backup](file-system-backup.md) or [the snapshot data mover](csi-snapshot-data-movement.md).
\ No newline at end of file
diff --git a/site/content/docs/v1.12/api-types/schedule.md b/site/content/docs/v1.12/api-types/schedule.md
index 37f671b5c..1a7cb9244 100644
--- a/site/content/docs/v1.12/api-types/schedule.md
+++ b/site/content/docs/v1.12/api-types/schedule.md
@@ -123,12 +123,12 @@ spec:
     ttl: 24h0m0s
     # whether pod volume file system backup should be used for all volumes by default.
     defaultVolumesToFsBackup: true
-    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
-    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     # Whether snapshot data should be moved. If set, data movement is launched after the snapshot is created.
     snapshotMoveData: true
     # The data mover to be used by the backup. If the value is "" or "velero", the built-in data mover will be used.
     datamover: velero
+    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
+    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     metadata:
       labels:
         labelname: somelabelvalue
diff --git a/site/content/docs/v1.13/api-types/schedule.md b/site/content/docs/v1.13/api-types/schedule.md
index e9afea460..5b96737c5 100644
--- a/site/content/docs/v1.13/api-types/schedule.md
+++ b/site/content/docs/v1.13/api-types/schedule.md
@@ -123,8 +123,6 @@ spec:
     ttl: 24h0m0s
     # whether pod volume file system backup should be used for all volumes by default.
     defaultVolumesToFsBackup: true
-    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
-    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     # Whether snapshot data should be moved. If set, data movement is launched after the snapshot is created.
     snapshotMoveData: true
     # The data mover to be used by the backup. If the value is "" or "velero", the built-in data mover will be used.
@@ -133,6 +131,8 @@ spec:
     uploaderConfig:
         # ParallelFilesUpload is the number of files parallel uploads to perform when using the uploader.
         parallelFilesUpload: 10
+    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
+    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     metadata:
       labels:
         labelname: somelabelvalue
diff --git a/site/content/docs/v1.14/api-types/schedule.md b/site/content/docs/v1.14/api-types/schedule.md
index e9afea460..5b96737c5 100644
--- a/site/content/docs/v1.14/api-types/schedule.md
+++ b/site/content/docs/v1.14/api-types/schedule.md
@@ -123,8 +123,6 @@ spec:
     ttl: 24h0m0s
     # whether pod volume file system backup should be used for all volumes by default.
     defaultVolumesToFsBackup: true
-    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
-    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     # Whether snapshot data should be moved. If set, data movement is launched after the snapshot is created.
     snapshotMoveData: true
     # The data mover to be used by the backup. If the value is "" or "velero", the built-in data mover will be used.
@@ -133,6 +131,8 @@ spec:
     uploaderConfig:
         # ParallelFilesUpload is the number of files parallel uploads to perform when using the uploader.
         parallelFilesUpload: 10
+    # The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
+    # When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
     metadata:
       labels:
         labelname: somelabelvalue