PLATFORM · AZURE BLOB
Migrate to Azure Blob Storage — from anywhere.
MigrationFox moves content into Azure Blob Storage from the places your data actually lives today: Windows file shares, SharePoint document libraries, OneDrive accounts, and Google Drive. Every upload is chunked, every write is verified against the blob’s content hash before we mark the item done, and every credential is held as a Shared Key or SAS token encrypted at rest. No silent success, no “looks like it worked”.
Supported Sources
Four source types land directly in a blob container without an intermediate cloud copy:
- SMB file shares — Windows, Samba, NetApp, any CIFS/SMB2/SMB3 target. The MigrationFox SMB agent runs inside your network, mounts the share, streams files through an authenticated channel to the API, and out to Azure. NTFS ACLs and timestamps are captured as metadata.
- SharePoint Online — full document libraries or a single folder, via Microsoft Graph. Version history, checked-out state, and column metadata are written as blob metadata so the archive is queryable later.
- OneDrive for Business — per-user drives or a tenant-wide sweep via admin consent. Useful for long-term archival of leavers’ OneDrive content under your compliance hold.
- Google Drive — personal and shared drives via a Google Cloud service account with domain-wide delegation. Native Google Docs are exported on the way through (Docs →
.docx, Sheets →.xlsx, Slides →.pptx) so the blob is immediately readable by Office tooling.
Chunked Uploads for Large Files
Anything larger than 64 MB is uploaded as staged blocks, not a single PUT. The engine splits the stream into 8 MB blocks, uploads up to four blocks in parallel per blob, and commits the final blob with a PutBlockList once every block is acknowledged. A dropped connection in the middle of a 50 GB file resumes from the last committed block, not from zero.
The same path handles SMB shares where a 200 GB disk image or a backup bundle is perfectly normal. You do not need to pre-split files, and you do not need the source file to fit in worker memory — reads are streamed block-by-block.
Authentication: HMAC-SHA256 Shared Key
MigrationFox authenticates to Azure Blob using Shared Key authorization, the native HMAC-SHA256 scheme documented by Azure Storage. On every request we build the canonicalised string (HTTP verb, headers, canonicalised resource) and sign it with the storage account key. That is the same mechanism azcopy and the Azure SDK use internally.
You can also supply a SAS token when you want a tighter grant — write-only, container-scoped, expiring in 7 days is a common choice for one-off migrations. Both credential types are encrypted at rest with AES-256-GCM and never written to application logs.
Custom Endpoints: GovCloud and Sovereign Regions
Not every Azure tenant sits on blob.core.windows.net. MigrationFox lets you override the storage endpoint per credential so the same job flow works for:
- Azure US Government —
blob.core.usgovcloudapi.net - Azure China (21Vianet) —
blob.core.chinacloudapi.cn - Azure Germany (sovereign) and other regional clouds with their own endpoints
- Azurite or another S3/Azure-compatible stack for dev testing
The endpoint is treated as configuration, not hardcoded. If Microsoft spins up a new sovereign cloud next quarter, you add one URL field and the migration works.
Verification on Every Upload
After each blob is committed, MigrationFox reads back the blob properties and compares the server-computed content hash with the MD5 we calculated streaming the file out. A mismatch marks the item verification_failed and the worker retries the transfer; it never appears as “done” in the UI until the destination confirms what we sent.
For multi-block blobs where Azure does not compute a single content MD5, we verify block-by-block as each PutBlock is acknowledged and record the full set of block IDs in the job record. If you ever need to prove a specific file landed correctly, the audit log has every block hash for it.
What You Get in the Job Record
- Source path, destination container and blob name, final blob size in bytes
- MD5 hash of the streamed bytes, plus the Azure ETag returned on commit
- Start and end timestamp, worker ID, bytes-per-second for the transfer
- Original source metadata (NTFS timestamps for SMB, version count for SharePoint, owner for OneDrive) written to
x-ms-meta-*headers on the blob - Any retry history if the transfer was not clean on the first attempt
Pricing
Azure Blob migrations are billed at $0.50 per GB transferred. Your account starts with 2 GB free — no credit card required. Discovery scans of any source are always free and unlimited; you only pay when bytes actually move.
Related
- How to migrate files to Azure Blob Storage (2026 guide) — setup walkthrough with a real storage account
- Amazon S3 platform page — the other common destination for file-share archival
- SMB file share source — how the in-network agent works