Skip to main content
The Zero Egress Migration (0EM) program is a managed service in which CoreWeave moves your existing object data from another cloud into CoreWeave AI Object Storage. CoreWeave runs the transfer with its migration partner, Flexify.IO, over a network path that avoids the standard internet egress fees your source cloud charges to move data out. Use the 0EM program when you have a large dataset in another cloud and want CoreWeave to handle the transfer. To copy data yourself with s5cmd or Rclone, see Migrate data to AI Object Storage instead.

​
Get started

The 0EM program isn’t available for self-service. You must arrange it through your CoreWeave account team as part of a storage agreement. Contact your account team to scope a migration. They confirm your eligibility, included volume, and destination capacity, then schedule a kickoff with Flexify to finalize the source inventory, credentials, and start window.

​
How the migration works

Flexify reads objects from your source buckets and writes them into your CoreWeave AI Object Storage buckets. It runs the transfer on data-mover VMs in your source cloud region, under its own cloud account, and routes the data to CoreWeave over private interconnects instead of the public internet. You configure and monitor the transfer in the Flexify web UI. The transfer has the following characteristics:
  • Copy, not move. Nothing is deleted from the source, so your existing workflows run without downtime during the migration.
  • Encrypted in transit and checksum-verified. Flexify validates an end-to-end checksum for every object and keeps a running tally, so you can confirm that each object arrived complete and uncorrupted.
  • No data retention by the partner. Flexify retains only metadata, such as object names and checksums, for tracking and reporting.
  • CoreWeave holds the contract. You don’t contract with Flexify separately. Flexify Inc. is a CoreWeave sub-processor.
Throughput depends on your source cloud’s read limits, your object-size distribution, available network capacity, and the transfer rate agreed with your account team. Migrations are designed for throughput of 1 PB per day or more.

​
Supported sources and scope

The program migrates data into AI Object Storage from AWS, Azure, Google Cloud, IBM Cloud, Alibaba Cloud, and Cloudflare. Other clouds and S3-compatible object stores can qualify if a zero-egress or low-egress transfer path is available. Your account team confirms eligibility for your source. The following scope and support details apply:
  • Transfer scope. Entire buckets, or only the prefixes and subfolders you specify.
  • Dataset size. No minimum.
  • Cadence. One-time, recurring, and incremental. An incremental re-sync transfers only new and changed objects.
  • Private environments. Supported when private connectivity is active between a supported cloud and CoreWeave and internet access is turned off on the CoreWeave side, such as over Direct Connect, because Flexify uses its own migration paths.

​
Included and paid migrations

A 0EM migration is either included in a storage agreement or purchased separately. Both use the same migration process, and only the commercial treatment differs. The included quota is cumulative: one-time, recurring, and incremental transfers all count toward it. It typically equals the storage capacity in your contract. You can migrate beyond that quota at CoreWeave’s standard migration rate. Choose a paid migration when you need to move more data than the included quota covers, or when you expect to import data continuously from another cloud and want migration costs separated from storage costs on your paperwork. Your account team confirms the migration rate, your included quota, and the capacity available in your target region.

​
Egress and other charges

On the 0EM path, you don’t pay your source cloud’s standard internet egress fees for the migrated data. You also don’t pay CoreWeave egress fees on that data once it’s in AI Object Storage, wherever you run your workloads. Two categories of source-cloud charges can remain your responsibility:
  • Google Cloud Storage (GCS) multi-region buckets. A migration from a multi-region GCS bucket avoids Google’s internet egress charge, but Google still bills regional egress at $0.02 per GiB. Single-region GCS buckets incur no egress charge. Budget for this separately.
  • Retrieval and operation charges. Your source cloud may bill archive or cold-tier retrieval fees, early-delete fees, or per-operation API charges on the buckets you migrate. CoreWeave can help estimate these once the source buckets and credentials are in place.

​
What you provide

Before the migration begins, gather the following. You enter both sets of credentials yourself in the Flexify UI.
  • Source inventory. The buckets, containers, and prefixes to migrate, with an estimated object count, total bytes, object-size profile, and storage class for each.
  • Source credentials. Read-scoped credentials for the source data. For Google Cloud Storage, Flexify requires HMAC keys, which you generate in the Google Cloud console under Cloud Storage > Settings > Interoperability. CoreWeave doesn’t supply a Google Cloud service account. A service account HMAC key needs storage.buckets.get, storage.objects.list, and storage.objects.get, plus storage.buckets.list if you want Flexify to enumerate buckets.
  • Destination buckets and credentials. Create a bucket for each destination, decide how source prefixes map onto them, and create access keys.
  • Schedule and contacts. Your preferred start window, any change-freeze constraints, the transfer rate you want to approve, and escalation contacts.
The migration principal is the CoreWeave principal that owns the access keys you give Flexify. Grant it these actions in an organization access policy:
  • s3:ListBucket
  • s3:GetBucketLocation
  • s3:PutObject
  • s3:AbortMultipartUpload
  • Optional: s3:GetObject, if validation or re-reads of migrated objects require it.
  • Optional: s3:ListAllMyBuckets. This is a global operation, so the statement that grants it must set "resources": ["*"].
Don’t put sensitive information in resource namesBucket, prefix, and object names can appear in migration logs and reports. Choose names that are safe to expose in those artifacts.

​
Migration phases

The following sections describe what CoreWeave and Flexify do at each stage of the migration, and what you do alongside them.

​
Before the migration

CoreWeave provisions AI Object Storage capacity in your destination Availability Zone against your organization’s quota, and sets up the network path from your source region. Flexify deploys its data-mover VMs. You get access to the Flexify web UI. The migration then starts with a small validation transfer. This confirms credentials, bucket mapping, routing, write access, object metadata behavior, and reporting end to end before any bulk data moves.

​
During the migration

Track object counts, transfer status, and completion in the Flexify web UI. Once data arrives, you can also monitor AI Object Storage capacity and performance in CoreWeave Grafana dashboards. During an active migration, CoreWeave can open a shared Slack channel with your team and Flexify. Flexify handles migration support directly in that channel, and CoreWeave assists with anything on the CoreWeave side, such as capacity, networking, or AI Object Storage configuration. Use your regular shared channel for account or platform topics outside the migration.

​
After the migration

Close the migration as follows:
  1. Reconcile the migration report against the agreed object count, byte count, and checksums.
  2. Record any failed or skipped objects, assign remediation owners, and confirm the acceptance criteria for closing the migration.
  3. Validate access to the migrated data with your S3-compatible tools, SDKs, and a representative workload.
  4. Decide separately whether to retain or delete the source data. Completing a migration doesn’t authorize CoreWeave or Flexify to delete anything at the source.
Once your data is in AI Object Storage, review Performance best practices for your object-size distribution and access pattern, and evaluate LOTA for read acceleration.
Last modified on October 9, 2026