Cloud Repatriation: Transfer Time Arithmetic, Data Gravity and Re-Platforming Risk

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Leaving a public cloud is limited less by the data transfer bill than by three other things: how long the copy takes while data keeps changing, what the provider will not export, and which managed services have to be rebuilt elsewhere. The major providers now credit transfer charges for customers who are genuinely leaving, on conditions that can shape the plan. Do the arithmetic and the export check before setting a date.

The commands below were not run in a lab. Names, sizes and rates are examples. Provider terms change, so re-read them before you rely on them.

Recommendations and interpretations are editorial unless attributed; source research is not lab validation.

Why it matters

"Repatriation" here means moving a workload from a public cloud to private infrastructure or a hosted private cloud.

A plan built on the size of the data alone tends to fail in one of two ways. The copy does not converge because the data changes faster than the backlog clears. Or the copy succeeds and the application cannot run, because something it depended on existed only as a provider service.

Data gravity is the informal name for the second effect. The more data sits in one place, the more applications, integrations and services gather around it, and the harder each of them is to move separately. It is a planning idea rather than a measurable law, so this article replaces it with things you can count.

How it works

Transfer time

The formula is simple:

time in seconds = bytes × 8 ÷ (link bits per second × efficiency)

The table uses decimal terabytes and shows the ideal time first, then the time at 70% efficiency. The 70% is our planning assumption for protocol overhead, retries and shared links. Replace it with a measured figure as soon as you have one.

Google's own transfer guide uses the same scale. It gives 12 days for 100 TB at 1 Gbps in one passage and "over 10 days" in another. Pure arithmetic gives 9.26 days, so treat any single headline number as a rough guide.

The TCP limit on one stream

A fast link does not make a single stream fast. RFC 6349 defines the bandwidth-delay product as round-trip time multiplied by bandwidth. It says the minimum TCP receive window is that figure divided by 8. The amount a sender can have outstanding is the smaller of the congestion window and the receive window.

Two worked examples (our arithmetic):

• 1 Gbps with 20 ms round trip needs a 2.5 MB window.
• 10 Gbps with 40 ms round trip needs a 50 MB window.

The same relationship caps a stream at window × 8 ÷ round-trip time. A 64 KiB window at 20 ms gives about 26 Mbps, whatever the link speed. TCP window scaling allows windows up to 1 GiB, so the protocol's own ceiling is rarely the limit. Host buffer settings and packet loss are the usual suspects.

Measure the real path before you trust a plan, using a sustained test across the actual route. RFC 6349 also gives a TCP efficiency percentage, based on bytes transmitted and retransmitted, which is a useful number to record.

Object counts cost time too

Bytes are only half the picture for object stores and file shares. An S3 listing returns at most 1,000 keys per request, so 100 million objects need at least 100,000 listing requests before a copy tool knows what exists (our arithmetic).

AWS describes request rates of 3,500 write and 5,500 read requests per second per prefix as the point at which to spread requests across prefixes. Reading 100 million objects from a single prefix at 5,500 per second takes at least five hours for the requests alone, because scaling happens gradually and you might receive 503 responses on the way. Time per object starts to dominate when objects are small.

File copies have the same problem at the destination. rsync's incremental recursion uses much less memory than building the whole list first, but some options disable it. Test on the real tree.

Convergence

While the first copy runs, the source keeps changing. If T is the first copy time, r is throughput and c is the change rate at the granularity your tool copies:

total time before the final sync = T × r ÷ (r − c)

This is our derivation, a geometric series of ever-smaller catch-up passes. If c is close to r, the time grows without limit. If c is greater than or equal to r, it never converges.

A worked example, with invented figures. Take 100 TB at 700 Mbps effective (7.56 TB a day) with 1 TB of change a day. The first copy takes 13.2 days and leaves 13.2 TB of backlog. Catching up takes about two more days, 15.2 in total.

The trap is the granularity of c. A tool that copies whole objects counts a one-byte change to a 5 GB object as 5 GB. A database that rewrites pages throughout a large file can look small in logical change and very large in changed blocks. Measure c by running a real incremental pass and counting what it sent.

Plan the final sync to fit inside your outage window, which means the last pass must be short. For a database you control, use database log shipping rather than a file copy. Managed databases may not offer it, as the Amazon RDS section below shows.

What to choose and why

Check the exit terms first

The three providers have published terms for leaving. All three are worth reading in full, because they differ.

Five planning consequences follow:

• All three speak of the internet. If you planned to use a private circuit because it is faster, check whether the credit still applies before committing.
• The clock matters. At 70% of 1 Gbps, 500 TB takes about 66 days for the first copy alone. That is more than a third of a 180-day window, and it misses Azure's 60 days unless you agreed a longer timeline in the first request. At 100 Mbps it cannot fit at all.
• Azure's condition collides with keeping the source. Credit needs every subscription cancelled, while good practice is to keep the source until the destination passes its checks. Decide which you are giving up, and keep the option of paying for the last weeks.
• Budget change data as chargeable on Google. Its wording covers data present at the notice, so data written during the move may fall outside it, and a trial copy before the notice may not qualify. Ask Google to confirm.
• Credits are not the same as no invoice. Google's credit arrives on the final invoices, issued after the Data Recovery Period, so allow for the cash timing.

The waivers cover transfer charges only. Requests, API calls, compute used to run the copy and storage while the move runs are separate costs to estimate.

Move by network or by device

Shipping can beat a slow link, but check that the option still exists.

AWS says Snowball Edge is no longer available to new customers. It points new customers to online transfer, Data Transfer Terminal or partners. Do not assume a device is available without confirming it for your account.

Azure Data Box can export as well as import, and Microsoft quotes up to 80 TB in a day over 10 GbE for the 80 TB device. Export has specific limits:

• It doesn't support case-sensitive file names. Microsoft says not to export two names differing only in case, because the files are overwritten on the device.
• It does not support data that is actively changing during export. A device export therefore needs a frozen source or a final online pass.
• It exports over SMB and is limited by SMB rules, so unsupported names are not exported.

Microsoft also says Data Box Heavy is retired and the 80 TB device will be retired in areas as next-generation devices arrive. Confirm which device can be ordered in your region before you plan around one.

Copying files with rsync

For file trees reachable over SSH, an rsync pass for repatriation looks like this. Check the options against your own data first:

rsync -aHAX --numeric-ids --sparse --partial --info=progress2 \
  source-host:/srv/data/ /srv/data/

-H, -A and -X preserve hard links, access control lists and extended attributes. --numeric-ids keeps owner numbers rather than mapping names, which matters if the two systems have different user lists.

By default rsync's quick check compares file size and modification time. A final pass with --checksum compares content instead, but both ends must read all the data, which the manual warns can slow things down significantly. Run it if you can afford that, and keep the result as evidence.

-a does not remove destination files that have since gone from the source, so a final pass leaves them in place. --delete removes them, and it destroys data if a path is wrong, so run it with --dry-run first and read the list. With -H, incremental recursion may send a hard-linked file again, which affects "just its efficiency".

Virtual machines: check export before you count on it

Do not assume a cloud machine can be exported as a disk image. AWS VM Export has hard limits:

• It can't export an instance containing third-party software provided by AWS. AWS's examples are Windows, SQL Server and anything created from an AWS Marketplace image.
• It can't export an instance with encrypted EBS snapshots in the block device mapping, or with instance-store volumes. EBS volumes attached after launch are not exported.
• Volumes larger than 1 TiB are not supported, and neither is an instance with more than one virtual disk or network interface. The image export page keeps the 1 TiB limit but lists no one-disk rule, so a multi-disk machine may have that route. Test it.
• The bucket cannot use SSE-KMS encryption.
• Instance export produces OVA, VHD or stream-optimised VMDK. The page describes compatibility with vSphere 4, 5 and 6, so test the import on your own hypervisor version. It writes only to an S3 bucket in the same account. Buckets with ACLs disabled are refused.

In practice that rules out AWS-licensed Windows machines. Those need replication with a tool that runs inside the guest, or a rebuild, plus licences for the destination. Any machine arriving on a new hypervisor may also need storage and network drivers prepared before it will boot.

Azure allows a managed disk to be downloaded as a VHD. The documented order is to stop the machine, wait for it to show as deallocated, generate a time-limited access URL and download. Microsoft limits that URL to 60 days. It also warns that snapshots of a running machine are like a machine that crashed, and that machines with data disks should be stopped first.

Disk size and a slow link can make a stopped machine a long outage. Calculate it from the table. Microsoft's alternative is to snapshot the managed disk and download the snapshot, which keeps the machine running. Stopping it for the snapshot alone gives a clean disk with an outage the length of the snapshot. That page covers Windows machines.

Databases: use the engine's own route

Do not copy a live database as files. Use the export route for the engine.

For Amazon RDS for SQL Server, native backup writes full .bak files to S3. The documented limits include 5 TB per file with multifile backup for larger databases, no more than 10 files at once, and the bucket must be in the same region. Backing up a database using transparent data encryption is supported, with its own procedure, so read that before you assume the file can be restored.

There is no log route on this path: you can't perform native log backups from SQL Server on Amazon RDS. You have full and differential backups only, so the outage is the backup, copy and restore time, unless you add a separate replication tool. A snapshot between the full and the differential forces a new full backup. Native backups can't run during the maintenance window or a snapshot, and are cancelled if they overlap the daily backup window.

Rehearse the restore on the destination and time it, because backup time on the old platform says little about restore time on new storage.

Keys

Encryption is where a move can stop without warning. On AWS, holding your own key material does not solve this. Keys can be imported so that you keep the original copy outside AWS, but the same page says AWS KMS does not support decrypting ciphertext from a symmetric encryption KMS key outside AWS KMS, even when the key material was imported.

So plan to read the data through the service while your permissions still exist, then re-encrypt under keys you control at the destination. Check the equivalent position for any other provider before you assume a copy of the key is enough.

Do this inventory before you start the exit clock. Keep the old keys until every restored copy has been verified.

Inventory what must be rebuilt

This is the re-platforming list, and it is usually the largest part of the work. Each row needs an owner and a tested replacement.

S3 compatibility has edges. Ceph's Object Gateway documents which S3 features it supports, and marks bucket replication as partial, permitted only across zones. Treat "S3 compatible" as a claim to test against the calls your application makes.

Risks and limits

• Terms move. AWS changed its program text as recently as 8 October 2026, according to the update notes in its post. Re-read each provider's page before committing to a date, and keep a dated copy.
• The fee waiver is not a capacity plan. Free transfer does nothing for time.
• Hidden second copies. Backups, logs, snapshots and audit data may have their own retention or regulatory reasons to stay. Decide what happens to each rather than finding out at account closure.
• Do not close the account early. Keep the source until the destination has passed restore and operations checks, inside any program deadline.
• Not covered: pricing comparison, licensing for bring-your-own Windows or SQL Server, and contract or legal advice. AWS's post also refers to EU and UK switching terms, which were not reviewed here.

Sources

Opened 2026-11-10.

• RFC 6349: Framework for TCP Throughput Testing, RFC 7323: TCP Extensions for High Performance
• AWS: Free data transfer out when moving out of AWS, Azure bandwidth pricing and FAQ, Google Cloud exit free data transfer request Azure: free egress steps and qualifications.
• AWS VM Export instance limits, image export limits, export prerequisites, Azure: Download a VHD
• Amazon S3 ListObjectsV2, S3 performance design patterns, Snowball Edge guide, Azure Data Box overview, Data Box limits, Google: Transferring large datasets
• RDS for SQL Server native backup and restore, AWS KMS imported key material, Ceph Object Gateway S3 API, rsync manual (Debian stable)

This article was originally published on 10 November 2026.