Export original files to another object store.

Export original files to another object store.

A clear, practical migration plan

1
Inventory what you have
Record source endpoints, buckets and prefixes, keys, counts, bytes and metadata. Include retained versions, delete markers, links, large files, encryption requirements, retention rules and the rate at which data changes.
2
Test the operations your transfer uses
Check source listing and reads, destination creation and writes, authentication, request signing, pagination, ranges and limits. Test the actual large-object and multipart behaviour required by your chosen transfer tool.
3
Decide what must be preserved
Choose current objects only or retained versions. Define key and metadata mapping, overwrite conflicts, deletes and links. Make explicit decisions for ACLs, IAM rules, custom tuples, storage classes, retention and holds rather than assuming they copy automatically.
4
Prepare destination capacity
Provide enough licensed logical capacity, physical replica or erasure-coding space, recovery headroom, CPU, memory and network bandwidth. Allow for temporary copies and transfer buffers before starting production-sized ingestion.
5
Create the required indexes first
Declare the supported index definitions before importing. Test field types, dates, arrays, extraction inputs and any embeddings or descriptors supplied by your application. Normal incoming object writes use the declared indexing path; no automatic model generation is implied.
6
Prepare and protect transfer credentials
Use the required source and destination permissions, TLS and restrictive secret files. Keep encryption keys available where needed. Do not place secrets in browser links, command history or logs; rotate temporary transfer credentials when the migration finishes.
7
Pilot representative files
Include JSON, media, empty files, unusual keys and very large objects. Verify original bytes, content types, metadata, version behaviour, expected queries and both authorised and unauthorised access before scaling up.
8
Transfer with bounded, resumable work
Use bounded concurrency and streaming rather than buffering whole large files. Configure retries and backoff, retain per-object successes and failures, and define how the selected tool resumes without silently skipping or duplicating work.
9
Verify keys, bytes and queries
Reconcile keys, counts and lengths. Compare independent byte hashes according to an agreed policy, verify metadata and sample downloads, then test representative index queries and required visibility. Do not assume every provider's ETag is a content hash.
10
Catch up changes, including deletes
Use a final delta transfer supported by your tools or arrange a controlled write pause. Reconcile overwrites and deletions explicitly. One listing pass is not a consistent snapshot of a changing source; use a resumable checkpoint or replay procedure where available.
11
Switch clients after verification
Update application endpoints and configuration only after acceptance checks pass. Smoke-test critical reads, writes, queries and public/private access. Monitor failures and preserve credentials without exposing them during the switch.
12
Keep a workable rollback route
Retain the source for an agreed period. Decide in advance how writes accepted after cutover are reconciled if clients return to the old system. Rehearse that decision rather than relying on an untouched old copy alone.
13
Exercise export and restore
Read original files into a tested S3-compatible destination or through supported native streaming APIs. Test interruption and restart of large transfers, reconstruction of original bytes and recovery from your independent backup procedure.
14
Retire the source deliberately
Remove old copies only after acceptance, recovery and retention requirements are met. Revoke temporary credentials and document any historical versions, metadata or access rules intentionally left behind.