If you are troubleshooting BitTitan connectivity failures without a clear picture of how MigrationWiz reaches your source and destination tenants at the network level, the underlying architecture is usually the missing piece.

MigrationWiz is a cloud service. When you create a source or destination endpoint, you are not deploying anything on-premises or on your local network that then connects outward. BitTitan cloud infrastructure initiates the connection and makes API calls from BitTitan published IP ranges directly to the tenant Exchange Online EWS endpoints or Microsoft Graph API endpoints.

That design has a direct consequence: conditional access policies, firewall restrictions, and IP allowlisting apply to inbound API traffic coming from BitTitan IP ranges, not from your corporate network. If the source tenant restricts API access by IP, BitTitan IP ranges must be explicitly allowlisted or jobs will fail at connection time.

BitTitan documents its IP ranges and connectivity prerequisites in its support content. In on-premises Exchange source scenarios, the Exchange CAS server EWS endpoint must be reachable from BitTitan IP ranges over HTTPS port 443. A firewall that blocks inbound connections from external IP ranges to on-premises EWS will cause every BitTitan job to fail at the connection attempt.

Before you run the first migration job, have you verified that BitTitan published IP ranges are allowlisted in both the source and destination tenant network configurations?

#BitTitan #MigrationWiz