diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
index 39260759..a4e98c7e 100644
--- a/docs/modules/ROOT/nav.adoc
+++ b/docs/modules/ROOT/nav.adoc
@@ -1,6 +1,14 @@
 .Get Started
 * xref:index.adoc[Overview]
-* xref:get-started.adoc[Deploy a Cluster]
+* 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
+* xref:get-started.adoc[Deploy cluster]
+* xref:lite-members.adoc[Deploy lite members]
 * xref:deploy-management-center.adoc[Deploy Management Center]
 * xref:connect-outside-kubernetes.adoc[]
 * xref:scheduling-configuration.adoc[Scheduling Hazelcast Pods]
diff --git a/docs/modules/ROOT/pages/get-started.adoc b/docs/modules/ROOT/pages/get-started.adoc
index 83822986..eac4f16c 100644
--- a/docs/modules/ROOT/pages/get-started.adoc
+++ b/docs/modules/ROOT/pages/get-started.adoc
@@ -7,6 +7,7 @@
 
 You need a Kubernetes or Openshift cluster, and the `kubectl` or `oc` command-line tool must be configured to communicate with your cluster.
 
+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