Migrate the complete S3 version chain
Godwit Sync records every S3 key and version ID as a separate task, then reads that exact source version during transfer. Noncurrent versions and delete markers retain their order.
The plan tracks history completeness per key
After the run, Godwit Sync groups task outcomes by key and classifies each version history as complete, partial, or fully skipped. The result identifies keys whose version history was not transferred in full.
- Reads the planned source version
- Requires destination bucket versioning
- Replays ordered delete markers
- --object-lock copies Object Lock
- Classifies each key's history
# List keys with partial version history
$ godwit plan list objects all \
--run-id version-history-prod \
--partial-history --json \
--state-path ./godwit.state.db
# Abridged JSON output
[
{
"key": "reports/q2.csv",
"storage_class": "STANDARD",
"status": "pending",
"version_id": "3Lg...",
"is_latest": true
},
{
"key": "reports/q2.csv",
"storage_class": "GLACIER",
"status": "glacier",
"version_id": "1Ra...",
"is_latest": false
}
]Version migration details
Does the destination keep the source version IDs?
No, the destination S3 service assigns an ID when it writes each version. Godwit Sync keeps the source ID as the task identity and records the returned destination ID.
How are archive-class gaps reported?
The planner assigns archived versions a dedicated status, so they remain in the plan. The per-key summary classifies each history as complete, partial, or fully skipped.
Which Object Lock settings are preserved?
With --object-lock, Godwit Sync copies the retention mode, retain-until date, and legal hold for each version. These settings are applied to the corresponding destination version after upload.
Explore related capabilities
Review the planned version chain before transfer.
Use --plan-only, then plan inspect to review versions, delete markers, and history gaps.