Azure Blob Storage Connector
Migrate files into an Azure Storage Account from any supported source. Blob Storage is destination-only in MigrationFox — use it as the target of file-class source connectors.
Credential Setup
The connector authenticates with an Azure Storage Account using an account name plus access key. Generate the key from the Azure Portal:
- Open portal.azure.com → Storage accounts and select the account you want to migrate into.
- In the left menu, go to Security + networking → Access keys.
- Click Show next to key1 and copy both the Storage account name and the Key value.
- In MigrationFox, open Connect → Azure Blob Storage, choose Account Key, and paste the account name, key, and target container name.
Rotate vs. revoke
Azure provides two parallel keys (key1 and key2) so you can rotate without downtime. If you ever need to revoke the key MigrationFox is using mid-migration, regenerate the other key first, switch MigrationFox to it, then regenerate the old one.
Custom Endpoints (Sovereign Clouds, Private Endpoints)
By default the connector targets https://<accountName>.blob.core.windows.net. For Azure Government (blob.core.usgovcloudapi.net), Azure China (blob.core.chinacloudapi.cn), or a Private Endpoint DNS name, pass an explicit endpoint value in the credential — the default is not derived automatically from the subscription's cloud.
Supported Source Platforms
Any file-class source connector can target Azure Blob Storage. The combinations validated in production as of this release:
| Source | Notes |
|---|---|
| SMB / Windows File Shares (via the MigrationFox Agent) | Agent streams directly from the local UNC path to Blob Storage with no relay through the API. See Agent troubleshooting if uploads stall. |
| SharePoint Online (document libraries) | Files migrate as block blobs under a prefix matching the source library path. |
| OneDrive for Business | Per-user OneDrive trees copy into a configurable prefix (often users/<upn>/). |
| Google Drive / Shared Drives | Google-native formats (Docs, Sheets, Slides) are exported to Office formats before upload — the same behaviour as the Google Drive → SharePoint path. |
Known Limitations
Soft-deleted blobs do not auto-restore
If the destination container has blob soft-delete enabled and a prior migration's blobs are still inside the retention window, the connector will create new blobs rather than undeleting the old ones. This is intentional — reviving soft-deleted blobs requires an explicit Undelete Blob call and MigrationFox does not write to deleted resources. If you need to resume on top of a retained generation, undelete the tree from the portal first, then run the migration in DELTA mode.
Custom endpoints must be explicit
For Azure Government, Azure China, or Private Endpoints, the endpoint field on the credential must be filled in manually — the connector does not infer it from the account name. A wrong default endpoint manifests as a cryptic DNS resolution failure on the first HEAD against the container.
- Block blobs only. Page blobs and append blobs are not written. Source files larger than the single-PUT threshold are uploaded as block blobs with chunked
PutBlock+PutBlockList. - Hierarchical namespace (ADLS Gen2) containers are supported for writes through the standard blob endpoint, but directory-level ACLs are not migrated — only the file content lands.
- Immutability policies. Containers with a legal hold or time-based retention policy reject overwrites; re-running a migration on an immutable container surfaces 409 conflicts that the connector does not retry past.
Troubleshooting
"Files don't appear in the portal after the migration completes"
This is the most common report and it is almost always a portal-side caching issue, not a migration failure. The Azure Portal's Storage Browser does not auto-refresh blob listings on a polling interval — the pane is populated on navigation. Click the Refresh button inside the container view (top toolbar of the blob list). Navigating away and back achieves the same effect.
To independently confirm the blobs are in place without the portal, from a machine with the Azure CLI installed:
az storage blob list \ --account-name <yourAccount> \ --container-name <yourContainer> \ --auth-mode key \ --account-key <key1> \ --output table
If the CLI sees the blobs but the portal does not, it is a portal refresh issue. If neither sees them, open the MigrationFox job details page and look for per-file error codes — the migration log records the exact upload result for every object.
"Connection test succeeds but uploads fail with 403"
Connection test only performs a container HEAD, which requires only the storage-account-level read permission embedded in the account key. Upload failures with 403 on a valid key indicate a container-level or account-level firewall rule. Check Networking → Firewalls and virtual networks and add the MigrationFox worker egress range, or switch to Enabled from all networks for the migration window.
Migrations from SMB appear to hang
When the source is SMB, the upload to Blob Storage is performed by the MigrationFox Windows Agent on your network, not by the MigrationFox cloud worker. If uploads stall, the issue is almost always local to the agent machine. See Agent troubleshooting for log locations, the Azure Blob HEAD verification sequence, and service-restart steps.