Migration planning
Runtime is in development. These guides explain design intent; they are not a released API or installation reference. Read the release policy →
No migration path is published yet
Section titled “No migration path is published yet”There are no public Runtime versions to migrate between on this website. No compatibility guarantee, automated migration command, or supported downgrade procedure is offered.
Plan migration as a change in contracts
Section titled “Plan migration as a change in contracts”A future migration guide must identify the source and target versions, affected schemas and APIs, changed defaults, and operational consequences. The absence of a compiler error does not prove unchanged integration behavior.
Review connector compatibility, input/output mappings, error categories, timeout handling, and retry behavior separately. Any stateful or externally visible change needs special attention.
Establish a rehearsal
Section titled “Establish a rehearsal”- Back up configuration and any applicable state using a verified procedure.
- Run representative fixtures against both versions in an isolated environment.
- Compare outputs, side effects, and failure behavior.
- Rehearse deployment and rollback without touching production dependencies.
- Define success criteria and the conditions that stop the rollout.
Make rollback specific
Section titled “Make rollback specific”A binary downgrade may not reverse a schema or remote side effect. A guide should distinguish restorable configuration, persistent-state changes, and actions that need compensation. Its rollback procedure must be tested where safe.
Publish from evidence
Section titled “Publish from evidence”Future migration notes should be linked from the exact release entry and corresponding versioned docs. They need the same reproducibility standard as installation guidance.
See configuration readiness and release lifecycle for the related publication requirements.