Data retention implementation
Introduce retention with a dry run that names every destination
Existing data needs policy mapping and review before destructive execution. Roll out in bounded batches and stop when the observed scope differs from the approved one.
In this article
Inventory legacy data and rules
Map data categories, trigger dates, copies and current exceptions. Older records may lack the event needed to calculate eligibility, such as a confirmed closure date.
Do not substitute a convenient timestamp without the policy owner's approval. Import time and original business completion time can imply very different retention outcomes.
Identify exports, old buckets and retired integrations that still hold relevant copies. A migration focused only on current application code can miss the longest-lived data.
Produce a non-destructive candidate report
Run the proposed eligibility logic without deleting anything. Show counts and representative sanitised cases by category, age, destination and hold state.
Have the responsible owners review ambiguous records and the intended scope. A unexpectedly large candidate set is a reason to investigate, not a sign that the new job is impressively efficient.
Use synthetic fixtures to verify boundary dates and exception handling independently of production statistics.
Execute a bounded first batch
Start with a reviewed scope and explicit stop conditions for unexpected counts, permission failures or destination mismatches. Record per-destination outcomes and preserve resumable progress.
Be honest about reversibility. A dry run is reversible, while an actual deletion may not be. Do not describe restoring an old backup as a routine undo if it would recreate data or discard unrelated new work.
For protected storage, confirm the configured lifecycle and lock behaviour before execution. A rule that expires current objects may not address every older version.
Expand only after verification
Check that completed records are unavailable through direct and derived paths and that reindexing does not recreate them. Rehearse backup restoration with the retention reconciliation control.
Resolve failed destinations before treating the migration as complete. Keep ambiguous legacy records assigned to owners rather than silently excluding them forever.
Update operating dashboards and support guidance to reflect the actual treatment and limits. The rollout should leave a sustainable lifecycle, not a one-time cleanup script whose assumptions nobody can explain next month.
Primary sources
AWS: object lifecycle managementAWS: Object LockReferences checked 11 September 2026.