diff --git a/docs/cloud/migrate/automated.mdx b/docs/cloud/migrate/automated.mdx
index de087b4034..9b5371d8b7 100644
--- a/docs/cloud/migrate/automated.mdx
+++ b/docs/cloud/migrate/automated.mdx
@@ -182,6 +182,27 @@ Proceed only when your request has been approved by Temporal.
 
 :::
 
+### Plan migration endpoints
+
+A migration endpoint is a cloud-side resource that connects one of your self-hosted servers to Temporal Cloud. Temporal
+creates the endpoints and provides the `endpoint-id` values used with the `tcld migration` commands in later phases.
+
+Each self-hosted server you migrate from needs its own S2S Proxy deployment and its own migration endpoint. You can
+migrate from more than one self-hosted server at the same time, such as separate development and production servers,
+provided each self-hosted server has a unique cluster name and Initial Failover Version. Temporal uses `active` as the
+default cluster name, so servers that still use the default will collide. See
+[Modify cluster configuration](#modify-cluster-configuration) for setting these values.
+
+If your self-hosted servers cannot use unique cluster names, migrate one server at a time, or contact Temporal to
+discuss the available options.
+
+Namespaces migrating from the same self-hosted server share that server's proxy and endpoint. You can migrate more than
+one Namespace from a server at the same time, provided each source Namespace and its cloud-side target are listed in
+the `namespaceTranslation` mappings of that server's proxy configuration. See
+[S2S Proxy configuration](#s2s-proxy-configuration).
+
+Tell Temporal how many self-hosted servers you plan to migrate from, and whether you intend to migrate from them in
+parallel, so that the required cloud-side resources are in place.
 
 ### S2S Proxy configuration
 
@@ -222,6 +243,9 @@ namespaceTranslation:
 ```
 5. Test access using the command below. It should display the information of the migration server.
 
+   The address is your own proxy's external address, not a cloud-side address. It's the same value you set as
+   `replicationEndpoint` under `clusterConnections` in your proxy configuration file.
+
 ```
 temporal operator cluster describe --address {the-outbound-external-address-of-your-proxy}
 ```
@@ -452,12 +476,9 @@ The following are known limitations.
 - OSS server versions 1.22 or newer are required. Refer to the
   [upgrade](/self-hosted-guide/upgrade-server#upgrade-server) procedure as needed.
 - History shard counts must be a power of two (eg. 512, 1024, etc...).
-- If you have multiple self-hosted servers and they are all configured with the same cluster name (by default Temporal
-  uses 'active' as cluster name), they cannot be connected to a single migration server simultaneously due to cluster
-  name collision. There are 2 available options:
-  1. Migrate one server at a time using a single migration server.
-  2. Create multiple migration servers (one for each self-hosted server) if you need to migrate all servers
-     simultaneously.
+- Self-hosted servers that are migrated at the same time must each have a unique cluster name and Initial Failover
+  Version. Servers that share a cluster name, such as the default `active`, collide. See
+  [Plan migration endpoints](#plan-migration-endpoints).
 - If you are using multi-cluster replication in your self-hosted setup and have previously failed over Namespaces, then
   this may impact your eligibility for automated migration. Specifically, whenever Global Namespace has been previously
   enabled the following restrictions apply:
@@ -502,6 +523,17 @@ The answer depends on your specific situation. However, automated migration is m
 
 In contrast, automated migration may not be the best solution if your self-hosted clusters do not meet the [minimum requirements](#limitations).
 
+### Can I migrate from multiple self-hosted servers at the same time?
+
+Yes. Each self-hosted server needs its own S2S Proxy deployment and its own migration endpoint, and each must have a
+unique cluster name and Initial Failover Version. See [Plan migration endpoints](#plan-migration-endpoints).
+
+### Can I migrate multiple Namespaces from the same self-hosted server at the same time?
+
+Yes. Those Namespaces share the server's proxy and endpoint, so no additional cloud-side resources are needed. Include
+each source Namespace and its cloud-side target in the `namespaceTranslation` mappings of that server's proxy
+configuration. See [S2S Proxy configuration](#s2s-proxy-configuration).
+
 ### Can I split Workflows from a single source Namespace into multiple cloud-side Namespaces?
 No. All Workflows will be migrated.