diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
index 8b3bab99..3b0598ac 100644
--- a/docs/modules/ROOT/nav.adoc
+++ b/docs/modules/ROOT/nav.adoc
@@ -4,6 +4,7 @@
 * xref:ask-ai.adoc[Ask AI]
 * xref:release-notes.adoc[Release notes]
 * xref:get-support.adoc[Get support]
+* xref:migrating-from-helm.adoc[Migrating From Helm Chart]
 
 .Deploy
 // Deploy options
diff --git a/docs/modules/ROOT/pages/get-started.adoc b/docs/modules/ROOT/pages/get-started.adoc
index 3b9e7f55..3ce46d40 100644
--- a/docs/modules/ROOT/pages/get-started.adoc
+++ b/docs/modules/ROOT/pages/get-started.adoc
@@ -9,6 +9,7 @@
 * The link:https://kubernetes.io/docs/tasks/tools/#kubectl[`kubectl`] or link:https://docs.openshift.com/container-platform/latest/cli_reference/openshift_cli/getting-started-cli.html[`oc`] command-line tools, configured to communicate with your cluster
 * link:https://helm.sh/docs/intro/install[`Helm`]
 
+NOTE: If you want to migrate from the Hazelcast Helm Chart, please follow the guidance in xref:migrating-from-helm.adoc[Migrating from Helm] document.
 
 == Step 1. Deploy Hazelcast Platform Operator
 
diff --git a/docs/modules/ROOT/pages/migrating-from-helm.adoc b/docs/modules/ROOT/pages/migrating-from-helm.adoc
new file mode 100644
index 00000000..4bc87650
--- /dev/null
+++ b/docs/modules/ROOT/pages/migrating-from-helm.adoc
@@ -0,0 +1,20 @@
+= Migrating From Helm Chart to the Operator
+
+Unfortunately there isn't any way to migrate without re-creating the cluster as the Operator needs to take control of the custom resources which were created by the Helm chart, which it is not possible.
+
+There are two ways to migrate from a cluster that is created by the Hazelcast Helm Chart.
+
+WARNING: For either solution to work, `persistence` must be enabled. You should also set the `cluster-data-recovery-policy` parameter's value to `PARTIAL_RECOVERY_MOST_COMPLETE` to avoid any issues during the restore process.
+
+== Restoring from a Backup
+
+Follow the steps below:
+
+1. Install Management Center. (if you didn't before)
+2. Trigger a backup using the Management Center user interface.
+3. Uninstall existing cluster. (Don't forget to keep PVCs)
+4. Follow the steps explained in the xref:backup-restore#restoring-from-persistent-volumes.adoc[Restoring from Persistent Volumes] section.
+
+== Attaching new Pods to Existing PVCs
+
+You can also restore your data to the cluster that is installed by the Operator without creating a backup. You just need to adjust the newly created Hazelcast CR's name correctly. The name of the new CR must be in the following format: `<name>-hazelcast-persistence`. For example, assuming that the older cluster was installed with `helm install hz hazelcast/hazelcast-enterprise` command, the new CR name must be `hz-hazelcast-enterprise` so that PVCs created by the Helm Chart will attach to the pods created by the Operator correctly.
\ No newline at end of file
diff --git a/docs/modules/ROOT/pages/scaling-upgrading.adoc b/docs/modules/ROOT/pages/scaling-upgrading.adoc
index 9ddb3e2f..2345d997 100644
--- a/docs/modules/ROOT/pages/scaling-upgrading.adoc
+++ b/docs/modules/ROOT/pages/scaling-upgrading.adoc
@@ -62,3 +62,19 @@ and you want to upgrade your Hazelcast version to {page-latest-supported-hazelca
 include::ROOT:example$/hazelcast.yaml[]
 ----
 
+Each Operator version has been tested and validated to work correctly with a specific Hazelcast version. You can find the test matrix below. We highly recommend you to consider it to avoid issues during Operator installations.
+
+[cols="1,1"options="header"]
+|===
+| Operator Version | Hazelcast Version
+| 5.5 | 5.1.4
+| 5.6 | 5.2.1
+| 5.7 | 5.2.3
+| 5.8 | 5.3.1
+| 5.9 | 5.3.2
+| 5.10 | 5.3.5
+| 5.11 | 5.4.0
+| 5.12 | 5.4.0
+| 5.13 | 5.5.0
+| 5.14 | 5.5.2
+|===
\ No newline at end of file