Migration Context Preservation Plan¶
Migration workflow — instantiates Carrier-Independent Work Identity Governance
Carries a work's meaning across a change of carrier by moving its metadata, interpretation context, dependencies, and usage conditions with it — not just the bytes.
A Migration Context Preservation Plan is a staged workflow executed when a work crosses from one carrier or system to another, whose job is to ensure the surrounding context survives the crossing, not only the payload. Its distinguishing idea is that it treats the move itself as the moment of danger — the boundary where meaning silently falls off — and plans explicitly for what must be carried, mapped, and checked so the work that arrives still means what the work that departed did. Copying the object is the easy part; preserving the context that made the object legible is the work this plan exists to do.
Example¶
A delivery courier wants to take five years of standing from one gig platform to a competitor. The naive move copies a number: "4.9 stars." The Migration Context Preservation Plan asks what that number means on the origin platform and what has to travel for it to mean the same thing on the destination: how many ratings back it (≈4.9 over ~4,000 trips is not ≈4.9 over 12), what the origin's scale was (a 5-star system remapped from a thumbs-up/down), which reviews were identity-verified, whether a past suspension is part of the record, and the fact that the origin counted only completed deliveries. The plan builds a mapping from the origin's schema to the destination's, flags what has no equivalent — the destination has no "verified customer" field, a loss to be recorded, not hidden — and carries the usage conditions with it (the rating may be shown to customers but not sold on for credit scoring). What lands is not a bare 4.9 but a portable reputation whose context is intact enough to be trusted.
How it works¶
- Inventory the context, not just the content — enumerate the metadata, interpretation assumptions, dependencies, and usage conditions the work silently relies on in its current carrier.
- Map old to new — build an explicit bridge from source fields, identifiers, and formats to their destination equivalents; where a mapping is lossy or absent, that is a finding, not a rounding error.
- Run the boundary loss check — before committing, test what would be lost or distorted in the crossing, especially the tacit context that lives in the origin system rather than in the object.
- Carry the rights and obligations — ensure the usage conditions and obligations attached to the work travel with it, so the destination inherits the same constraints.
Tuning parameters¶
- Context scope — how far out to draw the "context" boundary (immediate metadata only, or the full web of dependencies and assumptions). Wider is safer but can make a migration unfinishable.
- Loss tolerance — which losses block the migration versus which are recorded and accepted. Zero-loss is often impossible; this dial sets what "good enough" means.
- Mapping fidelity — exact field-to-field mapping versus best-effort approximation for fields with no clean equivalent.
- Verification depth — spot-check a sample versus validate every migrated instance against its source.
- Reversibility — whether the origin is kept live and rollback-able during and after the move.
When it helps, and when it misleads¶
Its strength is that it defends against the most common migration failure — moving the object and losing the meaning — by naming the tacit context that would otherwise evaporate at the boundary. The digital-preservation idea of significant properties[n1] is precisely its target: the properties without which the migrated thing is no longer the same thing.
Its failure modes come from the same place. Context is nearly bottomless, so an over-scoped plan can stall a migration indefinitely chasing dependencies that don't matter, while an under-scoped one declares success as the meaning quietly leaks. It can give false comfort — a plan that faithfully carries every field but misjudged which properties were significant preserves the wrong things — and it says nothing about whether the identifier still resolves afterward. The discipline is to derive the context inventory from a stated identity criterion (what must survive), record accepted losses openly rather than hiding them, and validate the arrived work against the departed one instead of trusting the copy.
How it implements the components¶
boundary_state_loss_check— its core test: what state, metadata, or meaning would be lost or distorted at the carrier boundary, run before the move is committed.legacy_mapping_bridge— the explicit source-to-destination mapping of fields, identifiers, and formats, including its flagged gaps.rights_and_obligations_scope_note— it carries the usage conditions and obligations across so the work arrives under the same constraints it left.
It moves the work safely but does not maintain the stable identifier that must keep resolving afterward — that is Persistent-Identifier Resolution Policy — nor hold the running inventory of manifestations, which is the Edition and Manifestation Catalog.
Related¶
- Instantiates: Carrier-Independent Work Identity Governance — the plan is how a work survives an actual change of carrier with its meaning intact.
- Consumes: Identity Preservation Checklist supplies the "what must survive" criterion the context inventory is built from.
- Sibling mechanisms: Persistent-Identifier Resolution Policy · Identity Preservation Checklist · Archival Provenance Metadata Template · Edition and Manifestation Catalog · Version Lineage Graph
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: The mechanism documents the mappings, context inventory, loss boundaries, dependencies, and usage conditions needed for a future carrier migration.
Nearest alternative: Protocol, Workflow & Routine — It can guide execution, but its operative form is the prospective migration specification rather than the enacted sequence.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Preserving metadata, provenance, dependencies, and interpretive context across carriers is archival and digital-curation practice.
Related originating lineages:
- Computer Science & Software Engineering — Digital migration supplies format conversion and dependency management.
- Material Culture & Museum Studies — Conservation practice emphasizes retaining meaning and use conditions, not merely physical substance.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Migration is one-way risk: once the origin is decommissioned, un-migrated context is unrecoverable. So the boundary loss check must run before the origin goes dark, and accepted losses should be logged where the destination's future custodians will actually see them — not in a migration ticket that closes and disappears.
[n1] Significant properties — a concept from digital preservation for the characteristics of a digital object that must be preserved through format migration or emulation for the object to stay authentic and usable. Deciding which properties are significant (and which are incidental) is the crux a migration plan lives or dies on. ↩