Merge pull request #7435 from fabriziopandini/clarify-clusterctl-move-limitations

📖 Clarify clusterctl move supported use case and limitations

Author: k8s-ci-robot

docs/book/src/clusterctl/commands/move.md

@@ -36,6 +36,28 @@ process completes.
 
 </aside>
 
+<aside class="note warning">
+
+<h1> Warning </h1>
+
+`clusterctl move` has been designed and developed around the bootstrap use case described below, and currently this is the only
+use case verified by Cluster API E2E tests.
+
+If someone intends to use `clusterctl move` outside of this scenario, it's recommended to set up a custom validation pipeline of
+it before using the command on a production environment.
+
+Also, it is important to notice that move has not been designed for being used as a backup/restore solution and it has 
+several limitation for this scenario, like e.g. the implementation assumes the cluster must be stable
+while doing the move operation, and possible race conditions happening while the cluster is upgrading, scaling up, 
+remediating etc. has never been investigated nor addressed.
+
+In order to avoid further confusion about this point, `clusterctl backup` and `clusterctl restore` commands have been
+deprecated because they were built on top of `clusterctl move` logic and they were sharing he same limitations. 
+User can use `clusterctl move --to-directory` and `clusterctl move --from-directory` instead; this will hopefully
+make it clear those operation have the same limitations of the move command.
+
+</aside>
+
 ## Pivot
 
 Pivoting is a process for moving the provider components and declared Cluster API resources from a source management