Most cloud contracts contain an exit clause. It grants the right to retrieve data and sets a notice period, and it is usually drafted without reference to how long the retrieval would actually take. A petabyte-scale dataset held in an archive tier, behind per-account request limits and an egress meter, does not move on legal timelines. The clause describes an entitlement. Whether that entitlement can be exercised inside the notice period is an engineering question, and it is rarely asked before notice is served.
European regulation has pushed in the same direction. The EU Data Act includes switching provisions intended to make moving between cloud providers practical rather than theoretical, covering contract terms, the phasing out of switching charges, and duties to assist. Rules of that kind change what a provider must offer. They do not change how many objects an organization holds, how those objects are spread across storage classes, or whether the receiving platform can absorb them at the rate the source will emit them.
A plan that consists of a clause and an assumption is not a plan. One that states a measured volume, a measured rate, the attributes that will not survive the copy, and a method for proving the result complete, is.
Egress volume and the restore that comes first
The first number to establish is the volume that has to cross the network, not the volume that appears on an invoice. Provider-side compression or deduplication does not reduce what is transferred if objects are rehydrated on read. Record object count alongside capacity, because transfer tooling behaves very differently against a hundred million small objects than against the same capacity in a million large ones. Small objects are governed by request overhead rather than bandwidth.
Objects in archive storage classes are not readable until restored. Restore is a separate operation with its own latency, per-request charge and throughput ceiling, and it produces a temporary copy that expires. If the transfer does not reach an object before its restore window closes, that object must be restored and paid for again. For a large archive footprint the restore phase can occupy more calendar time than the copy phase, and it has to be sequenced so restored batches are collected before they lapse.
Rate limits set the pace more often than bandwidth
Object storage services apply request-rate ceilings per account, bucket or key prefix, and enforce them by throttling rather than queuing. A tool that opens more parallel connections in response to slow progress usually makes matters worse, since the extra requests are rejected and retried. Sustained exit throughput is generally a function of requests per second accepted without throttling, multiplied by average object size.
Enumeration is its own bottleneck. Listing a bucket holding hundreds of millions of keys is a paginated operation that can run for hours before a byte is copied, and it restarts if the run does. Providers offer inventory reports because listing at that scale is impractical. Rate-limit increases are usually available on request and usually have a lead time, and that lead time belongs in the plan rather than in the notice period, since slow-down responses during a time-boxed exit look exactly like a failing transfer.
What travels with the objects and what does not
An object is data plus a set of attributes, and copy tools differ widely in which attributes they preserve. User-defined metadata usually survives. Creation and modification timestamps generally do not, since the destination assigns its own. Storage class, object tags, access control entries, bucket policies, lifecycle configuration and notification settings are properties of the source platform and must be recreated rather than copied. Where those attributes drive retention or billing, losing them changes how the data is treated afterward.
Retention state deserves separate attention. Object Lock periods and legal holds are enforced by the platform holding the object, so a copy arrives without them unless the process reapplies equivalent settings against the original retention clock. Versioning raises the same question: the exit has to decide whether it copies current versions only or the full history including delete markers, and the second option multiplies capacity and object count. Which attributes exist and where they live is the subject of metadata residency, approached from the other end.
Proving the copy is complete
A transfer tool reporting success is a statement about the tool. Evidence means an independent count and an independent comparison. Count objects and bytes at the source at a fixed point in time, count them at the destination after the run, and account for every difference rather than accepting a close match. Differences will exist, because the source keeps taking writes while the copy runs, so the plan needs a cutover point after which the source is read-only.
Content verification is stronger than counting, and costs more. Comparing stored checksums avoids re-reading data, but entity tags are not reliable content hashes for objects uploaded in multiple parts, since they encode part structure as well as content. Where verification matters, read a statistically meaningful sample back and hash it, using the approach described for verifying migrated data.
| Exit stage | What fails quietly | What to check |
|---|---|---|
| Enumerating the source | Listing pages incompletely or misses objects written during the run | Counts from an inventory report and a live listing, each timestamped |
| Restoring archive objects | Restore windows expire before the transfer arrives and objects are skipped | Objects restored against objects transferred, and the expiry per batch |
| Transferring data | Retries mask truncated writes, leaving correct keys holding wrong content | Per-object byte size at both ends, plus checksums on a sample |
| Preserving attributes | Tags, retention state and storage class dropped without an error | Attribute comparison on a sample from every bucket, not only the largest one |
| Versioned buckets | Current versions copied, history and delete markers left behind | Version count per key on a sample, against the retention obligation |
| Final reconciliation | Source keeps accepting writes after the count was taken | Write access disabled at a recorded time, then a delta pass |
Where Scality RING fits
RING is software-defined object and file storage running on standard x86 servers in the operator's own facility. In an exit it is usually the destination, and what matters is whether it can absorb the volume and hold it under the same rules. Capacity is expanded by adding nodes and servers to a live system without taking the namespace offline, which matters when the receiving platform is still being built while a transfer is already running.
RING presents an S3-compatible API and supports versioning and S3 Object Lock, so retention state and version history can be reconstructed on arrival rather than abandoned. Erasure coding and replication are selectable per policy, making the durability scheme a local decision. Geographic placement across sites is configured by the operator, so location after the exit is a property the organization sets. Because the system runs in the customer's own facility, physical location, network boundaries, key management and administrative access are held locally.
Rehearsing a partial exit
Exit capability is testable, and the test is a partial exit against real data on a fixed schedule, annually and after any significant change in footprint. Pick one production bucket holding archived, versioned and retention-bound objects, and copy it end to end with the tooling that would be used for real. Time enumeration, restore and transfer separately, since they scale differently.
Record the results as numbers, not impressions: objects and bytes per second sustained, throttling responses seen, attributes that did not survive, and cost incurred. Extrapolate to the full footprint and compare that figure with the contractual notice period. If it exceeds the notice period, the gap is a risk-register finding, and the options are a longer notice period, a phased exit starting with cold data, or a change in how data sits across storage classes today.
Maintain an inventory beside the rehearsal: which buckets carry retention obligations, which hold data under residency constraints, and which are large enough to need their own transfer window. That inventory also feeds procurement checks on subcontractors, since every party holding or moving the data must eventually be unwound.