Recovery Considerations
Fallback, rollback, and recovery framing for migration-sensitive operations.
Recovery Considerations in SGEN is the framing for the moments after something goes wrong during migration work. Where Backups handle the safeguard, Import handles the entry path, and Post Migration handles validation, Recovery Considerations handles the explicit framing for what to do when validation surfaces a blocking issue, when an import does not behave as expected, or when a Search and Replace pass produces unintended changes.
This page is the Reference definition of the recovery posture — what fallback options exist, when rollback is the right call, and how escalation is shaped when in-platform recovery is not enough.
What is this for?
Read this page when you want the structural definition of SGEN's recovery posture for migration-sensitive operations — what to do when something has gone wrong, how the platform supports rollback, and what discipline applies before escalation.
The page is a Reference definition. It does not walk you through running a specific recovery — those procedures live in Guides and in incident-response runbooks.
Good use cases
- A migration import has produced unexpected results and the team needs the rollback framing.
- Validation during Post Migration surfaced a blocking issue and the operator needs to decide between fix-in-place and rollback.
- A Search and Replace pass produced unintended changes and the cleanup needs to be undone.
- A planned high-stakes operation needs the recovery path scoped before execution begins.
- A stakeholder asks "what happens if the migration goes wrong?" and the team needs the structural answer.
What NOT to use this for
- Step-by-step recovery procedures — open the relevant Guide.
- Per-customer infrastructure recovery — escalate to support.
- Per-release shipped behavior change — open What's New or Changelog.
- Routine staging-vs-live promotion — that uses normal workflow tools.
How this connects to other features
- Migration and Import Overview — parent Reference area.
- Backups — the safeguard recovery depends on.
- Post Migration — the validation cycle that surfaces issues recovery responds to.
- Import — the entry path; recovery often returns to the pre-import state.
- Search and Replace — bulk operation whose unintended outcomes recovery may need to undo.
Definition
Recovery Considerations is the framing for what to do when migration-sensitive work has produced an unexpected outcome. The framing covers the decision shape (fix-in-place vs rollback), the rollback mechanism (restore from backup), the escalation discipline (when in-platform tools are not enough), and the post-recovery validation that follows.
The defining property is response. Recovery is a response to an event that already happened. The discipline is what converts a surprising outcome into a recoverable one.
Purpose
The purpose of this page is to define the recovery posture as a Reference layer rather than as a procedural runbook. It explains what options exist, when each option applies, and how the recovery cycle pairs with Backups (the safeguard) and Post Migration (the validation cycle that surfaces the need).
Scope
This page covers recovery considerations at the Reference level — the framing rather than the procedure.
The page covers:
- The decision shape (fix-in-place vs rollback vs escalate).
- The rollback mechanism (restore from backup snapshot).
- The escalation discipline.
- The post-recovery validation cycle.
- The boundary against Backups (the safeguard) and Post Migration (the validation).
- Step-by-step recovery procedures — Guides.
- Per-incident response — incident runbooks.
- Per-customer infrastructure recovery — support escalation.
- Per-release shipped behavior change — What's New or Changelog.
Where to find it
Recovery operations originate in two places: the Backups panel at the admin → Settings → Backups (for restore from snapshot) and the support escalation queue (for infrastructure-level recovery beyond the admin surface). For most in-scope recovery decisions, the Backups panel is the entry point.
The decision shape
When something goes wrong, the first decision is between three options.
Fix in place
Apply a corrective change to the current state and continue forward. Best when the issue is well-understood, scoped to a small number of records, and the corrective change has low risk of compounding the original problem.
Rollback
Restore from the pre-event backup snapshot and rescope the operation. Best when the issue affects many records, when the corrective change is unclear, or when the original operation may have side effects that are hard to fully understand from the symptom alone.
Escalate
Hand off to support or platform-eng. Best when in-platform recovery tools are not enough — when the issue suggests platform-level behavior change, when the recovery path itself fails, or when the situation needs an authority outside the team running the migration.
Recovery framing
Choose the path
What is the scope of the issue?
Is the corrective change well-understood?
The rollback mechanism
Rollback in SGEN runs through the Backups system. The team identifies the pre-event snapshot, restores to staging first, validates the restored state via Post Migration, then promotes staging to live.
Restore-to-staging-first discipline
Restoring directly to live is supported but reserved for confirmed-need cases. The recommended posture is restore to staging, validate, promote. The discipline costs minutes and saves hours when the restored state itself needs adjustment.
Post-rollback validation
After rollback, walk the Post Migration validation cycle to confirm the restored state holds up. Recovery is not complete until validation passes; treating rollback as automatically successful skips the same gate that the original migration was supposed to clear.
Escalation discipline
When in-platform recovery is not enough, escalation hands off to support or platform-eng. The escalation handoff carries the relevant context: what was attempted, what failed, what state the site is currently in, what backups are available, what time window the team is operating against.
When to escalate
- Recovery itself is failing (rollback does not restore the expected state).
- The issue suggests platform-level behavior change rather than per-site state.
- The team has exhausted in-platform recovery options and the site is still in a non-production state.
- A regulated or contractual deadline forces external authority.
Escalation context
Provide the snapshot identifier, the timeline of events, the validation results that surfaced the issue, and the recovery actions already attempted. Support and platform-eng can move faster with full context than with partial information.
Constraints and boundaries
Recovery Considerations is a Reference area for the framing of recovery decisions. It is not a substitute for incident-response runbooks or for per-customer support engagement.
Use Recovery Considerations for:
- Framing the decision between fix-in-place / rollback / escalate.
- Scoping the recovery path before high-stakes operations begin.
- Stakeholder communication about the platform's recovery posture.
- The actual restore operation.
- Step-by-step incident response.
- Per-customer escalation and infrastructure recovery.
Public boundary
This page is intentionally public-safe. It does not expose recovery internals, escalation runbooks, or protected operational identifiers.
Examples
Example 1 — Validation surfaces a structural import failure
Post Migration structural validation reveals that a custom-field schema did not transfer cleanly. The operator opens this page, decides between fix-in-place (rebuild the custom field structure on staging) and rollback (restore the pre-import snapshot, rescope the import to handle the schema mapping). The Reference frames the decision; the operator chooses based on the specific failure shape.
Example 2 — Search and Replace touched more records than intended
A bulk replacement matched a substring more broadly than expected and produced unwanted changes across 200 records. The operator opens this page, decides rollback is the right call (the affected scope is too broad to fix per-record cleanly), restores from the pre-replacement snapshot, rescopes the find pattern more tightly, and reruns the operation.
Example 3 — Recovery itself is failing
A rollback restore completes but the restored state still shows the issue the rollback was meant to undo. The operator opens this page, recognizes the escalation criterion, opens a support ticket with snapshot identifier + timeline + attempted actions, and pauses migration work until support engages.
Documentation guidance
Use this page as the structural definition for the recovery framing. Procedural detail belongs in Guides and in incident runbooks; per-release behavior change belongs in What's New or Changelog. Cross-reference Backups for the rollback mechanism and Post Migration for the validation cycle that surfaces the need.Reading order
Open this page after Backups and Post Migration so the safeguard layer and the validation cycle are anchored. Read this page proactively before any high-stakes migration window so the recovery framing is in place before it is needed.
Related reading
- Migration and Import Overview — parent Reference area.
- Backups — rollback mechanism.
- Post Migration — validation cycle that surfaces the need for recovery.
- Import — operation that may need recovery if it does not behave as expected.
- Search and Replace — operation whose unintended outcomes recovery may need to undo.
Vocabulary cross-reference
- Fix in place is applying a corrective change to current state without rolling back.
- Rollback is restoring from a pre-event backup snapshot.
- Escalate is handing off to support or platform-eng when in-platform recovery is not enough.
- Pre-event snapshot is the backup taken before the operation that needs recovery.
- Restore-to-staging-first is the recommended discipline of restoring to staging, validating, then promoting.
Maintenance discipline
When recovery options or escalation criteria change across releases, update this Reference and log the change in Changelog. The framing stays valuable because the three-decision shape (fix / rollback / escalate) stays small. New recovery tooling should land inside the existing decision shape rather than expanding it into more options.