More context to warning message (neo4j#551) (neo4j#619)

As per request

Cherry-picked from neo4j#551

Author: lidiazuin

modules/ROOT/pages/clustering/internals.adoc

@@ -182,11 +182,40 @@ If you are running a multi-data center cluster, then upstream strategies for bot
 Remember that for Read Replicas this also affects from where transactions are pulled.
 See more in xref:clustering-advanced/multi-data-center/configuration.adoc[Configure for multi-data center operations].
 
+=== Using the Replica instance in case of failure
 
-[WARNING]
+In case of failure (e.g. a partial failure of a cluster due to the loss of an instance, but not of the majority), you may transform a Read Replica instance into a Core instance as a way to restore the cluster's core availability.
+However, keep in mind that this is not advised as it could cause data loss and complications in the Raft group.
+
+To avoid that, the _read_replica_ instance must not be initialized as a *single* instance, nor be introduced in a different or new cluster. 
+This action would cause an override of the raft state, thus preventing the replica from successfully joining the targeted cluster.
+
+After performing that change, follow these instructions to unbind the Replica instance and update the discovery configurations amongst cluster members: 
+
+. Ensure that the converted _read_replica_ currently belongs to the same cluster that it will be re-introduced back to, as a _core_. 
+This can be done by performing `CALL dbms.cluster.overview()` and verifying the instance's address and cluster mode.
+
+. Stop and unbind the _read_replica_ instance.
+
+. Update the cluster mode configuration in _neo4j.conf_, from `dbms.mode=READ_REPLICA` to `dbms.mode=CORE`.
+
+. Stop Neo4j on the removed core instances that are not intended to serve as core members. 
+
+. Unbind those instances from the cluster by performing `neo4j-admin unbind` while they are stopped. 
+This action will prevent such instances from subsequently attempting to rejoin the running cluster.
+
+At this point, the previous _read_replica_ (now _core_) instance may be introduced into the running cluster. 
+To persist this change in the cluster's architecture, the following configuration updates are advised:
+
+- On the previous _read_replica_ (now _core_) instance, set `causal_clustering.discovery_advertised_address` and `causal_clustering.discovery_listen_address` as appropriate.
+
+- Update the `causal_clustering.initial_discovery_members` configuration with the currently valid list of discovery addresses for each member of the cluster.
+This should replace the addresses of any removed _core(s)_ with the discovery addresses of the previous _read_replica_ (now _core_) instance.
++
+[NOTE]
 ====
-* Do not transform a Read Replica into a Core.
-* Do not transform a Core into a Read Replica.
+In cases where `causal_clustering.discovery_type` is other than `LIST`, make sure to update the corresponding address resolution addresses records. 
+For example, DNS A records for discovery types DNS and SRV, and any Kubernetes service address alternate to reflect the inclusion of the _read_replica_ discovery address.
 ====
 
 [[causal-clustering-on-disk-state]]