This article explains how to diagnose and resolve a common network error that can occur during a migration, indicating that a connection was abruptly terminated.
1. Symptom
During a migration, the process fails for one or more items, often intermittently. The migration logs show the following low-level network error:
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
This is a generic error from the operating system's networking layer, not directly from the CloudM Migrate application itself.
2. Cause
This error means that a network connection that was successfully established between the CloudM Migrate server and the remote platform (e.g., Microsoft 365, Google Workspace, or an on-premises server) was suddenly and unexpectedly terminated.
CloudM Migrate established a connection, but before the data transfer was complete, the connection was cut off by a device or service between the two endpoints. The most common causes are:
-
Stateful Firewalls or Security Gateways: This is the most frequent cause. Many corporate firewalls (e.g., Palo Alto, Fortinet, Cisco ASA) inspect network traffic. They may interpret a long-running, high-volume migration connection as suspicious or idle and terminate the session based on a security policy or timeout rule.
-
Network Proxies: A web proxy or security appliance that sits between the migration server and the internet may have its own connection timeout policies that are shorter than what the migration requires.
-
Load Balancers: If migrating from an on-premises system like Exchange, a hardware load balancer can terminate sessions based on its own rules.
-
General Network Instability: Unreliable network infrastructure, packet loss, or high latency between your server and the destination can cause connections to drop.
-
Remote Server Issues: In rare cases, the destination platform itself may be experiencing high load and could terminate connections.
3. Resolution
Resolving this issue requires investigating the network path from the CloudM Migrate server to the remote platform. The goal is to identify which device is closing the connection.
Step 1: Investigate Firewall and Proxy Logs
Work with your network security team to analyze the logs from your corporate firewall and any other security appliances.
-
Look for log entries that correspond to the exact time the migration error occurred.
-
Filter the logs for traffic originating from the IP address of the CloudM Migrate server.
-
Search for actions like "deny", "drop", "reset", or "session timeout" associated with this traffic. This is often the smoking gun, pointing to a specific security policy that is terminating the connection.
Step 2: Configure Firewall and Network Devices
Once the responsible device is identified, adjust its configuration to allow the migration traffic.
-
Create Explicit Allow Rules: Create a specific firewall rule that allows all outbound traffic on the required ports (typically TCP 443) from the CloudM Migrate server to the required IP addresses and URLs for the source/destination platform.
-
Disable Packet Inspection: For this specific rule, disable advanced security features like Deep Packet Inspection (DPI), SSL/TLS Inspection, and Intrusion Prevention, as these can interfere with long-lived migration connections.
-
Increase Timeouts: If the issue is caused by a session timeout, increase the timeout value for the specific rule governing the migration traffic.
Step 3: Test Network Stability
If firewall logs show no issues, check the stability of the internet connection itself.
-
From the CloudM Migrate server, open a Command Prompt or PowerShell window.
-
Run a continuous ping to the remote platform's endpoint (e.g.,
ping outlook.office365.com -t). -
Let this run for an extended period. Look for any "Request timed out" messages or significant, recurring spikes in the response time (latency). Any packet loss indicates an unstable connection that needs to be addressed by your network provider.
Step 4: Review CloudM Migrate Retry Settings
As a final measure, you can ensure CloudM Migrate is configured to handle temporary network blips. In the tool's configuration, confirm that the Retry Count and Retry Delay settings are set to reasonable values to allow the tool to recover from brief connection drops.