# Flag rollback history retention timeline | SourceX

Canonical: https://refer.sourcex.si/guides/preserve-feature-flag-incident-rollback-records
Last updated: 2026-10-18

Before a flag platform is replaced, inventory four facts for each record type: what it is, the years it covers, who owns the system, and the real date access ends. Then look at the order in which records disappear. Dashboard recovery checks usually go first, chat messages go at whatever retention the workspace sets, and the old platform's change history ends with its contract. Incident timelines and postmortems tend to survive. Nothing should be kept without the authority to keep it.

This timeline is part of the [feature flag incident rollback guide](/guides/workflow-feature-flag-incident-rollback). Where that guide explains which records show a rollback decision, this page does one job: it lays out how long each of those records tends to last around a platform change, and who has to approve keeping any of them.

## The retention timeline: what fades first

Read the timeline from left to right, from today to the day the old platform is switched off. Each record type has its own end point.

1. **Recovery checks seen only on dashboards: often gone already.** A responder watched a graph recover and closed the incident. If the check was never written into the incident or the postmortem, the evidence lives only in monitoring data, which is usually kept for a limited period set by the monitoring plan. Ask the platform team what that period is.
2. **Incident channel messages: gone at the chat retention setting.** Slack, for example, keeps all messages for the lifetime of the workspace by default, but owners on paid plans can set messages to be deleted after a set period, can set different retention on individual channels, and deletions cannot be undone. If incident channels have short retention, the reasoning between alert and rollback may already be partly lost.
3. **Webhook copies of flag changes: gone with the channel or tool they were sent to.** Many teams send flag change events to chat or to the incident tool. Those copies follow the receiving system's retention, not the flag platform's.
4. **Old flag platform change history: gone at contract end or decommission.** This is the record most at risk in a replacement. LaunchDarkly's change history, previously called the audit log, records changes to flags and other resources in each environment with the member, resource, environment, date and a diff, and its REST API can list audit log entries filtered by time, resource and member. That is detailed history, and it sits in an account the company stops paying for.
5. **Incident timelines: usually survive.** PagerDuty's documentation says it never deletes incidents; the Account Owner can redact one, which deletes its description and incident key and cannot be undone. Other incident tools differ, so ask.
6. **Postmortems: usually survive, if the wiki does.** They sit in a document store with no fixed expiry, unless the wiki itself is migrated.

## Record by record: lifespan, end point and approver

| Record type | Where it lives | What ends it | Tends to last | Who approves keeping it |
|---|---|---|---|---|
| Dashboard recovery check | Monitoring tool | Metric retention on the plan | Weeks to months, plan-dependent | CTO, on legal advice |
| Incident channel messages | Team chat | Workspace or channel retention setting | Workspace lifetime by default, or a set period | IT owner with legal |
| Flag change webhooks | Chat or incident tool | Receiving system's retention | Same as the receiving system | IT owner with legal |
| Old flag change history | Old flag platform | Contract end, account closure or database drop | Until cutover, unless preserved | CTO and CFO, with legal |
| Incident timelines | Incident platform | Account closure or redaction | Long-lived; vendor-dependent | On-call lead's executive |
| Postmortems | Wiki or document store | Wiki migration or cleanup | Long-lived | Engineering director's executive |

The pattern matters more than any single number: the records that explain why a rollback was scoped the way it was (chat and dashboards) are the shortest-lived, and the record that shows exactly what changed (flag history) is the one a replacement strands.

## What a replacement moves, and what it strands

A flag platform migration moves what the new platform needs to serve traffic. It rarely moves the past.

| Typically moved | Typically stranded |
|---|---|
| Live flags and their current variations | Every past change to targeting, with who made it and when |
| Current targeting rules and segments | Retired rules, old segments and rollouts that ended |
| Environments still in use | Environments renamed or retired years ago |
| SDK keys and integrations | Change events archived only in chat or incident tools |

The same stranding happens in other system changes. The [legacy Access database migration guide](/systems/migrate-microsoft-access-database-legacy) describes it for an older database, and the [archive versus backup comparison](/compare/data-archiving-vs-backup) explains why a backup taken for restore is not always a readable history.

## Four facts to collect before cutover

Ask the engineering director for four facts, all at metadata level:

- **Record classes:** flag change history, incident timelines, incident channel messages, written recovery checks, postmortems.
- **Coverage:** first and last year of each, including any flag system retired before the current one.
- **Owners:** who administers each system, and who holds each vendor contract.
- **The real deadline:** the date the old platform's contract ends, the account closes or the database is dropped, in writing. A plan for "sometime next quarter" is not a deadline.

That date is the only urgency worth naming. A partner should not suggest exporting or keeping anything the company is not authorized to keep. The inventory exists so the people with authority can decide in time. DevOps consultants who also handle tool offboarding can pair this with the [MSP client offboarding checklist](/resources/msp-client-offboarding-checklist).

## Who must approve keeping it, and the qualification check

Keeping history after a contract ends is a company decision. The CTO usually decides whether engineering supports it, legal checks customer and vendor terms, the CFO approves any spend, and the CEO, or the owner-CEO in an owner-run company, approves any new use. The [licensing authority decision tree](/questions/who-can-license-feature-flag-incident-rollback-records) covers the licensing side, and the [rollback system map](/guides/feature-flag-incident-rollback-records-across-systems) tells you which keys must survive for preserved records to stay useful.

The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Unknown until SourceX reviews it: buyer interest, how customer names in messages are handled, the rights review result and any offer.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's old flag platform has a written shutdown date and years of change history behind it, [register as a partner](/register), check the company against [who qualifies](/who-qualifies), and read the [program terms](/terms) before that date arrives.

## Sources

- https://launchdarkly.com/docs/home/releases/change-history
- https://launchdarkly.com/docs/api/audit-log/list-audit-log-entries
- https://slack.com/help/articles/203457187-Customize-data-retention-in-Slack
- https://support.pagerduty.com/main/docs/incidents
- https://refer.sourcex.si/terms