How to Migrate Azure Blob Storage to Google Cloud Storage—and Back Again

Choose the migration path

Direction	Recommended first choice	Best for	Important credential
Azure Blob Storage → Google Cloud Storage	Google Cloud Storage Transfer Service	Large, repeatable, or scheduled transfers into GCS	Azure account-level SAS with Blob service, Container and Object resource access
Google Cloud Storage → Azure Blob Storage	AzCopy	One-time or scripted small-to-medium transfers with precise control	GCS service-account key plus Azure Entra ID or SAS authorization
Google Cloud Storage → Azure Blob Storage	Azure Storage Mover	A managed migration job with repeat runs and centralized Azure monitoring	GCS HMAC credentials stored in Azure Key Vault
Either direction, complex transformation	A pipeline or migration platform	File conversion, content filtering, application-level transforms	A design specific to the workload

The tools do not create a universal two-way synchronization layer. Decide which system is authoritative, define what happens to objects created during the migration window, and choose whether the project is a one-time cutover or a staged migration with recurring delta runs.

1. Inventory the source before copying

Record the source account or project, containers or buckets, prefixes, object count, total bytes, largest objects, storage classes or access tiers, versioning, retention policies, legal holds, soft-delete settings, encryption configuration, metadata, and the applications that read or write the data.

Create a migration manifest for every source container or bucket. At minimum, capture:

• Source object name and destination object name.
• Object size and content type.
• Source generation, ETag, MD5 or CRC checksum when available.
• Last-modified time and any business metadata required by the application.
• Whether the object is current, archived, soft-deleted, held, or a historical version.
• The destination bucket or container and the prefix mapping.

Do not assume that Azure Blob tiers and Google Cloud Storage classes are interchangeable. Build an explicit mapping. For example, Azure Cool or Archive may need a business decision before becoming GCS Nearline, Coldline, or Archive. Archived data may need to be rehydrated before it can be copied, which can affect both schedule and cost.

2. Prepare both clouds

Azure prerequisites

1. Confirm the target storage account, region, redundancy, namespace type, and container layout.
2. Decide whether the destination should use flat namespace or hierarchical namespace behavior.
3. Create the destination container and apply its IAM, lifecycle, retention, encryption, and network policy before the first production copy.
4. For an Azure source used by Google Storage Transfer Service, create a least-privileged account-level SAS token. Grant only the Blob service, Container and Object resource types and the permissions required by the transfer, normally Read and List. Restrict the protocol to HTTPS and set an expiration long enough for the planned transfer window.
5. Store the SAS token in a protected secret-management system. Do not put it in shell history, a ticket, a Git repository, or the article's command line.

Google Cloud prerequisites

1. Create or select the destination project and bucket.
2. Choose the bucket location and storage class deliberately; changing location later is a migration, not a setting change.
3. Enable the Storage Transfer Service API and confirm the service account used by the transfer has permission to write the destination bucket.
4. For a GCS source used by AzCopy, create a dedicated service account with only the required bucket access and generate an interoperability HMAC key if the selected AzCopy workflow requires it. Store the JSON key or HMAC secret outside the working directory and rotate or revoke it after the migration.
5. For Azure Storage Mover's GCS S3-compatible path, generate GCS HMAC credentials and store them in Azure Key Vault rather than placing them in a script.

3. Migrate Azure Blob Storage to Google Cloud Storage

For a large or repeatable Azure-to-GCS migration, use Google Cloud Storage Transfer Service. Google documents Azure Blob Storage as a supported source and uses an Azure SAS token to authenticate the source. The destination is a Google Cloud Storage bucket.

Create a pilot transfer

Start with one non-critical container or a narrow prefix. Keep the source online and writable while the pilot runs.

A typical gcloud command is:

The credentials file should be protected and contain the SAS value in the format required by the Google Cloud Storage Transfer Service documentation. Replace every placeholder before running the command. Never paste a real SAS token into a shared terminal transcript.

To transfer all containers in one Azure storage account, Google documents the account-level wildcard form:

Use the wildcard only when the destination layout and permissions have been designed for multiple containers. It is usually safer to pilot one container first and then create explicit jobs for production prefixes.

Configure overwrite and deletion behavior deliberately

For an initial migration, copy objects without deleting anything at the source. Decide whether destination objects with the same name should be overwritten, skipped, or compared. A transfer that mirrors deletions can turn a source-side mistake into destination data loss; do not enable deletion behavior until the retention and rollback plan is approved.

Monitor the transfer

Use the Google Cloud console or gcloud transfer operations list and gcloud transfer operations describe to monitor the operation. Capture the transfer's object counts, bytes copied, skipped objects, and errors. Retry errors after correcting permissions or source conditions rather than treating a successful job submission as proof that the data arrived.

4. Migrate Google Cloud Storage to Azure Blob Storage

There are two practical approaches. Use AzCopy when you want a direct, scriptable copy with precise control. Use Azure Storage Mover when a managed Azure migration job, repeat runs, and centralized monitoring are more important than using a generally available command-line workflow.

Option A: AzCopy for a controlled copy

Microsoft documents AzCopy support for copying from Google Cloud Storage to Azure Storage. The copy is performed directly between the cloud storage services rather than routing all object bytes through the administrator's workstation.

Set up authentication using protected credentials. A simplified object-prefix example is:

Authorize the Azure destination with Microsoft Entra ID, a user delegation SAS, or an appropriate container SAS according to your environment. If the destination URL includes a SAS, keep the full URL out of shell history and process listings where possible. Use a dedicated migration identity and grant only the destination permissions it needs.

Run a dry run or a narrow prefix first. Then capture the AzCopy job ID and inspect the job log. A zero exit code means the command completed; it does not replace object-count, byte-count, and checksum validation.

Option B: Azure Storage Mover for a managed GCS-to-Azure job

Azure Storage Mover supports a GCS S3-compatible source migration path that uses GCS HMAC credentials stored in Azure Key Vault. This path is currently documented as a preview capability, so confirm regional availability, limits, and support status before selecting it for a production cutover.

The high-level sequence is:

1. Enable GCS interoperability and create HMAC credentials for the source identity.
2. Store the access key and secret key as separate secrets in an Azure Key Vault.
3. Give the Storage Mover source endpoint identity permission to read those secrets.
4. Create a GCS S3-compatible source endpoint using the HTTPS GCS endpoint and the Key Vault secret URIs.
5. Create an Azure Blob container target endpoint.
6. Create a migration project and job definition, starting with a small prefix.
7. Run the job, review errors, and validate the destination before scheduling repeat runs.

Use this route when the team wants Azure-native job management and can accept the preview status of the GCS source feature. Do not assume it provides the same object semantics as a native Azure-to-Azure migration.

5. Decide what happens to metadata, versions, and access control

Object content is only part of the migration. Before production copy, decide how to handle:

• Content type, cache-control, content-disposition, and custom metadata.
• Object tags and user-defined metadata.
• Azure blob snapshots and versions versus GCS object generations and versions.
• Azure container ACLs and RBAC versus Google Cloud IAM and uniform bucket-level access.
• Retention policies, legal holds, immutability, and lifecycle rules.
• Customer-managed encryption keys and the identities allowed to use them.
• Source storage tiers and destination storage classes.

Do not promise a one-to-one ACL conversion. Azure RBAC, container ACLs, GCS IAM, ACLs, signed URLs, and object conditions have different models. Design destination access from the application's requirements instead of blindly reproducing source permissions.

6. Validate the destination

Validation should combine independent checks. For each migrated container or bucket:

1. Compare expected object count with the destination count.
2. Compare total bytes, allowing for any explicitly excluded versions or prefixes.
3. Compare a manifest of object names and sizes.
4. Compare checksums for a representative sample and for every object when the tool and source provide compatible checksums.
5. Verify content type and required metadata on representative objects.
6. Test application reads, writes, range requests, signed URLs, and lifecycle behavior.
7. Confirm that retention, legal hold, encryption, and logging controls are active at the destination.
8. Review transfer errors and confirm there are no unresolved permission or naming failures.

For very large migrations, store the source and destination manifests in a separate audit location. A sample check is useful, but it is not equivalent to a complete manifest comparison.

7. Perform a low-risk cutover

Use a staged cutover rather than switching clients immediately after the initial copy:

1. Freeze the migration scope and record the source manifest.
2. Run the initial bulk transfer.
3. Keep the source authoritative while the destination is validated.
4. Stop or quiesce application writes during a short maintenance window, or use a documented delta-transfer strategy.
5. Transfer the final delta.
6. Validate the final object count, bytes, and application reads.
7. Change the application configuration, endpoint, secret, or DNS record to use the destination.
8. Monitor errors, latency, access denials, and object creation after cutover.
9. Keep the source read-only for the agreed rollback period.
10. Revoke temporary SAS, HMAC, and migration credentials only after the retention and rollback decision is complete.

If both clouds must remain writable, do not improvise bi-directional replication with two independent copy jobs. Define conflict resolution, deletion propagation, version handling, and a loop-prevention mechanism first. In many environments, a single authoritative writer plus read-only replication is safer.

8. Troubleshoot common failures

Authentication failures

Check that the SAS, HMAC, service-account, or Entra credentials are valid, not expired, scoped to the correct account, and allowed through the source and destination network policies. A credential that can list a container may still lack permission to read object content or write the destination.

Objects are missing

Check prefix filters, wildcard placement, excluded extensions, archived or soft-deleted source objects, and whether the transfer tool treats virtual directories as prefixes. Compare the tool's error report with the source manifest.

Names or metadata changed

Cloud providers have different naming and metadata rules. Check case, URL encoding, reserved characters, trailing slashes, content headers, and metadata-key normalization. Test the application's expected object names before cutover.

The job is slow or expensive

Check object count, small-object overhead, cross-region egress, request charges, throttling, and the selected storage class. For many small objects, application-side packaging or a managed transfer service may be more efficient than thousands of individual requests—but only if the application can consume the resulting layout.

The transfer completed but the application fails

Test the destination with the application's identity, not an administrator account. Validate IAM, signed URL generation, CORS, content type, range requests, encryption permissions, and any hard-coded provider-specific endpoint or metadata assumptions.

Migration checklist

• [ ] Source inventory and manifest captured.
• [ ] Destination region, class, redundancy, and namespace selected.
• [ ] Versioning, retention, legal hold, and archive behavior documented.
• [ ] Least-privileged source and destination credentials created.
• [ ] Credentials stored outside scripts, shell history, and repositories.
• [ ] Pilot prefix transferred and validated.
• [ ] Object counts and total bytes compared.
• [ ] Checksums and metadata spot-checked or fully compared where supported.
• [ ] Application reads, writes, signed URLs, and range requests tested.
• [ ] Final delta and cutover window approved.
• [ ] Source retained read-only for rollback.
• [ ] Temporary credentials revoked after the rollback period.

Bottom line

Azure Blob Storage and Google Cloud Storage can be migrated in either direction, but the safe method depends on the direction and scale. Use Google Storage Transfer Service for a managed Azure-to-GCS transfer, AzCopy for a controlled GCS-to-Azure copy, or Azure Storage Mover when its documented preview path fits a managed Azure workflow. The migration is not complete when the transfer job says “done.” It is complete after the destination passes manifest, integrity, permissions, application, and rollback checks.

Sources

• Google Cloud Storage Transfer Service overview
• Google Cloud: Configure access to Microsoft Azure Blob Storage
• Google Cloud: Transfer all containers in an Azure Storage account
• Microsoft Learn: Copy from Google Cloud Storage to Azure Storage with AzCopy
• Microsoft Learn: Azure Storage migration guide
• Microsoft Learn: Get started with Google-to-Azure migrations in Azure Storage Mover

*Azure, Microsoft, Google Cloud, Google Cloud Storage, and related product names are trademarks of their respective owners. This independent guide is for planning and operational education; test the exact commands and permissions in a non-production scope before a cutover.*