Skip to main content

Migration and recovery

Moving an existing job to the platform and adopting an enhanced runtime are separate changes. Identify which components will change before planning the rollout.

Inventory the current job​

Record Flink and CDC versions, connector artifacts, JAR dependencies, SQL and UDFs, state backend, checkpoint storage, source offsets and target write behavior. Preserve the existing configuration and a known recovery procedure.

Validate the change​

  • Check API, SQL, dependency and connector compatibility for the target release.
  • Validate Checkpoint or Savepoint compatibility for the actual source and target versions. Do not assume a state snapshot is portable across arbitrary versions.
  • Test restoration with representative state and data.
  • Check output correctness, including duplicates, updates, deletes and catch-up after recovery.
  • Measure any interruption and recovery time under the intended operating procedure.

Agree on rollout and rollback​

Decide who performs each step, what permits the rollout to continue, when to stop and how to return to the previous deployment. Some upgrades change state or metadata in ways that constrain rollback; validate the return path explicitly.

The website does not promise universal binary compatibility, zero downtime or zero-code migration. The supported path is defined by the releases involved and the outcome of the evaluation.

For deployment or migration assistance, review the support scope and contact the team.