Migration and Import
How data and site state are brought into SGEN — import, validation, recovery. Risk-aware reference, separate from day-to-day administration.
Migration and Import in SGEN is the area covering how data or site state is brought into the platform, how recovery-sensitive operations are handled, and what validation needs to happen before a migrated site is treated as production-ready. This area is risk-aware by intent — the operations documented here can affect site state in ways that day-to-day administration does not.
This page is the Reference definition of the Migration and Import surface. It establishes how migration operations should be understood as a structured process with explicit safeguards, where the boundary sits between routine administration and risk-sensitive work, and how the per-operation Reference pages (Backups, Import, Post Migration, Recovery Considerations, Search and Replace) descend from this Overview.
What is this for?
Read this page when you want the structural definition of the Migration and Import surface — what counts as migration work, what safeguards the platform provides by default, where the boundary sits between Migration and routine SG-Admin work, and how the per-operation Reference pages relate to one another.
The page is a Reference definition. It does not walk you through any specific migration. Per-operation procedural detail lives in the corresponding Migration sub-pages and in Guides.
Good use cases
- You are scoping a site migration into SGEN and need to understand the structural shape of the import process.
- You are planning a recovery-sensitive operation (restore from backup, post-migration validation, search-and-replace pass) and need the platform's safeguards laid out.
- You are explaining to a stakeholder how SGEN handles the risk envelope around migration without exposing implementation detail.
- You hit a question about a specific migration operation and want the platform-role context before opening the per-operation page.
- You are designing internal SOPs and need the migration model to anchor handoff between teams.
What NOT to use this for
- Step-by-step migration procedures — open the relevant Guide.
- Per-operation capability detail — open the corresponding Migration sub-page.
- Routine site administration that does not affect site-wide state — open the admin Reference.
- Per-customer infrastructure detail — escalate to support.
- Per-release shipped behavior change — open What's New or Changelog.
How this connects to other features
- Platform Overview — the system map placing Migration and Import inside the Reference library.
- SG-Admin Overview — imported records, settings, and migrated site state become visible inside the admin.
- Workflows Overview — migration and recovery operations frequently depend on workflow handoff sequencing.
- Automation Overview — backups, deployment-adjacent behavior, and recovery-sensitive operations intersect with guarded automation paths.
- Backups — per-operation Reference for backup operations.
- Import — per-operation Reference for import operations.
- Post Migration — per-operation Reference for post-migration validation work.
- Recovery Considerations — per-operation Reference for recovery-sensitive paths.
Definition
Migration and Import references describe how data or sites are brought into SGEN, how recovery is handled, and what validation needs to happen before a migrated site is treated as production-ready. This area is read as a risk-aware Reference layer rather than as a day-to-day administration guide.
The defining property is durability of effect. Migration operations affect site state in ways that ordinary administrative changes do not — imported content arrives as a batch, restored snapshots replace current state, search-and-replace passes can touch many records at once. The Reference treats these operations with the discipline that durability demands.
Purpose
The purpose of this page is to define the migration and import scope within the SGEN stack, clarify how import and recovery-related operations fit into the platform, and provide a stable Reference model for validation, fallback, and post-migration handling.
Scope
This Reference area covers migration and import activities that move data or site state into SGEN. It also covers safeguards, validation points, and recovery considerations tied to those activities.
The area covers:
- Migration and import activities that move data or site state into SGEN.
- Safeguards, validation points, and recovery considerations.
- Risk-sensitive steps documented separately from standard day-to-day administration.
- The boundary against routine SG-Admin work, Workflows, and Automation.
- Routine administrative procedures that do not affect site-wide state — SG-Admin Reference.
- Per-area task procedures — Guides.
- Per-release shipped behavior — What's New or Changelog.
- Per-customer infrastructure or environment detail — support escalation.
Where to find it
Migration and import operations are available under the admin → Settings → Import (for data ingestion) and the admin → Settings → Backups (for snapshot capture and restore). For a full migration, work through the Import panel first, then validate against a backup snapshot before promoting to production.
Responsibilities
The Migration and Import area is responsible for making data movement and recovery-sensitive operations understandable at a platform level.
Import model definition
Defines how imported data or migrated site state should be understood within the SGEN platform. The import model is the structural shape — what arrives, where it lands, how it is identified after the import — and the Reference is the operator-facing description of that shape.
Validation guidance
Clarifies where validation needs to occur before migrated state is treated as stable or production-ready. Validation is the discipline that converts an import event from "data arrived" into "data verified" — and the Reference frames where that verification belongs in the migration cycle.
Recovery awareness
Documents the fallback, rollback, and recovery considerations that matter when migration work does not behave as expected. Recovery awareness is the disciplined framing for the moments after something goes wrong — how the platform supports rollback, where the recovery path starts, what the operator should not assume.
Key elements
The Migration and Import section currently includes the following per-operation Reference pages:
| Operation | What it covers |
|---|---|
| Backups | How backups are scheduled, stored, and restored — the foundational safeguard for all other migration work. |
| Import | How data or site state is brought into SGEN — the entry path for migration operations. |
| Post Migration | How a migrated site is validated, cleaned up, and promoted to production-ready state. |
| Search and Replace | How content-wide changes are handled when post-migration cleanup requires bulk replacement. |
| Recovery Considerations | How fallback, rollback, and recovery-sensitive paths are framed when migration work does not behave as expected. |
Site-tier · Risk-aware operations
Migration & Import
Backups
Snapshots, retention, restore-to-staging-first
Open Backups →Import
Bring data into SGEN from external source
Open Import →Post Migration
Validate before treating as production-ready
Open validation →Search & Replace
Bulk content/URL adjustment after import
Open S&R →Recovery
Fallback, rollback, recovery framing
Open Recovery →Operational role
In operational terms, this area exists to separate migration-sensitive work from normal administrative behavior. It provides a Reference layer for activities that can affect larger site state, imported content integrity, recovery options, and readiness decisions after data movement has occurred.
In daily operator use, Migration and Import is opened during specific events — a customer migration, a recovery operation, a planned bulk-content change, a post-incident restore. Most operators do not work in this surface day-to-day; the Reference exists so that when they do open it, the structural model is already there.
Dependencies and related surfaces
Migration and Import should be read alongside the parts of the platform that own site records, operational handoffs, and guarded background behavior.
SG-Admin
Imported records, settings, and migrated site state often become visible or manageable through the admin surfaces. The Migration pillar inside the admin is the per-site working surface for migration operations; the Reference here covers the structural model behind them.
Workflows
Migration and recovery operations frequently depend on controlled handoff points and validation-aware workflow sequencing. The Workflows Reference covers the cross-product process flow; the Migration Reference covers the risk-aware framing of the operations inside that flow.
Automation
Backups, deployment-adjacent behavior, and recovery-sensitive operations intersect with guarded automation paths. The Automation Reference covers the trigger / schedule / integration-event model; the Migration Reference covers the risk-aware framing for migration-relevant automations.
Architecture and Reliability
The architectural framing for the platform's environment separation, controlled change model, and recovery posture lives in Architecture and Reliability. The Migration Reference assumes that framing and applies it to the per-operation discipline.
Constraints and boundaries
This Reference area defines migration scope, safeguards, and recovery considerations. It does not replace operational runbooks, onboarding instructions, or release communication.
Use Migration and Import for:
- Reference definitions for migration, import, validation, and recovery operations.
- The risk-aware framing for operations that affect site-wide state.
- The boundary against routine SG-Admin work and against per-task Guides.
- Task-by-task procedures and walkthroughs.
- Routine administrative procedures that do not affect site-wide state.
- Shipped changes and release-specific updates.
Public boundary
This page is intentionally public-safe. It does not expose private infrastructure detail, internal credentials, exact backup-storage internals, or protected service identifiers. Architectural depth lives in Architecture and Reliability and the per-operation Reference pages, all written to the same public boundary.
Examples
Example 1 — Operator runs a planned recovery from backup
The operator decides to restore a site to a known-good snapshot after an editorial change introduced unexpected behavior. They open the Migration and Import → Backups Reference for the structural model (what backups exist, what restore does, what state the site returns to), then open the matching Guide for the procedure. The Reference frames the operation; the Guide walks the steps. After the restore, they open the Post Migration Reference to confirm the validation discipline they should apply before treating the site as production-ready again.
Example 2 — Migration operator imports a content batch from another platform
The migration operator opens the Migration and Import → Import Reference for the import-model framing (what arrives, where it lands, how the imported records are identified afterward). They scope the import per the Reference, run it via the admin → Migration, then open the Post Migration Reference and Search and Replace Reference for the post-import cleanup discipline. The Migration Reference area carries them through the structural framing for the entire arc.
Example 3 — Stakeholder asks "what does SGEN do if a migration goes wrong?"
The platform lead opens the Recovery Considerations Reference for the fallback / rollback / recovery framing, then pairs it with the Backups Reference for the foundational safeguard. The two Reference pages together give the stakeholder a structured answer: the platform provides backup-based recovery as the primary safeguard, and the Migration area documents the framing for using it when migration work does not behave as expected.
Documentation guidance
Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — operation additions land as new sub-pages under the Migration and Import section rather than as a new top-level Reference area.
Procedural instruction belongs in Guides; per-release behavior change belongs in What's New or Changelog. Per-operation capability detail lives in the corresponding sub-page, not in this Overview.
Reading order across the section
Open the Migration and Import Overview (this page) first to anchor the model. Then open per-operation Reference pages in the order that matches your work — Backups for the foundational safeguard, Import for the entry path, Post Migration for validation discipline after the import lands, Search and Replace for bulk-content cleanup, Recovery Considerations for the framing when something goes wrong.
The per-operation pages can be read in any order; this Overview is the structural assumption every per-operation page leans on.
Related reading
- Platform Overview — system map.
- SG-Admin Overview — where migration operations are administered.
- Workflows Overview — workflows that include migration steps.
- Automation Overview — automation paths that include backup and recovery behavior.
- Architecture and Reliability — architectural framing for environment separation and controlled change.
- Shared Concepts — vocabulary the migration operations assume.
Vocabulary cross-reference
- Migration is the canonical term for moving data or site state into SGEN. Body copy may use "import" interchangeably for batch operations.
- Import is the per-operation entry path for bringing data into SGEN.
- Backup is a recoverable snapshot of site state used for restore and operational safety.
- Restore is the operation that returns site state to a previous backup snapshot.
- Post-migration validation is the discipline of verifying migrated state before treating the site as production-ready.
- Recovery is the framing for the moments after something goes wrong during migration work.
Maintenance discipline
When a new migration operation lands, add a new per-operation sub-page and link it from the Key Elements table. Do not expand the responsibility model unless the new operation genuinely introduces a category not covered by import-model / validation-guidance / recovery-awareness. The page stays valuable because the responsibility framing stays small.
When an operation is retired, mark the corresponding sub-page as deprecated, leave it on disk for historical reference, and remove the row from the Key Elements table. The principle is the same as elsewhere: the live Reference shows live state; archived material is preserved but not surfaced as if it were current.
Pairing with Architecture and Reliability
For migration work that touches the platform's environment separation or controlled change model — promoting a migrated site from staging to live, restoring across environments, validating that recovery preserved the architectural posture — pair the Migration Reference with the Architecture and Reliability section. The architectural pages explain the structural commitments behind the platform's recovery and change-control posture; the Migration Reference here applies that posture to per-operation discipline.
The pairing matters most during high-stakes migration windows. The architectural page gives stakeholders the framing that explains why the platform handles recovery the way it does; the Migration Reference gives operators the operational discipline for executing inside that framing. Reading the two together gives the team the structural confidence to plan, execute, and verify migration work without inventing per-customer ad-hoc procedures.
When this page is the right first read
This page is the right first read when an operator, a stakeholder, or a documentation author needs the structural framing for SGEN's migration and import discipline. It is not the right first read when the question is about a routine SG-Admin operation (open the admin Reference instead) or about a step-by-step procedure (open Guides instead). Migration operations earn their own Reference area because they affect site state durably; routine work does not, and lives elsewhere.
The Migration Reference area, paired with Backups and Recovery Considerations sub-pages, is meant to be the team's anchor during the highest-stakes operations the platform supports. Reading it once during onboarding and revisiting it before every planned migration window is the discipline this Reference is shaped for.