> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Move to a new Compute version
description: >-
  Move an integration to a new Compute version safely. What changes in your request, quote, result
  and client, what is preserved, and when a fresh quote or approval is required.
route: /docs/compute/reference/migration-guide
page_id: docs-compute-reference-migration-guide
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: 'Integrators upgrading a working Compute integration to a new version'
voice: D
reader_question: 'How do I move to a new version without breaking my integration?'
primary_action: Quote again against the new version
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-reference-migration-guide-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

Write down the four versions you run today:

- the contract release from a recent response
- the `workflow.version` you pin
- your profile version
- your client version

Read the change entry for the version you are moving to, and note whether it names any of those four.

Run the migration in the sandbox first, against a small input you already know the answer to.

One thing you do not have to prepare: your identities survive a migration. Personal, service and automation identities and their keys stay valid. You do not re-mint a key to move version, and rotation stays a separate deliberate act.

Your sources, destinations and profiles also survive. A profile may need a new version if the new workflow narrows what it accepts, but the profile itself is not replaced.

## Migrate the request

The seven TaskSpec objects do not change shape between versions. What changes is what a workflow version accepts inside them.

1. Point `workflow.version` at the new version.
2. Validate `parameters` against that version's generated `parameters_schema`.
3. Check whether your profile still narrows `policy`, `quality`, `output` and `limits` legally.
4. Correct every mismatch before you submit anything.

An unknown or unsupported field is rejected, never dropped. That is in your favor here: a setting that no longer applies refuses loudly instead of disappearing.

## Quote again, always

A quote is signed against one described request. It carries an expiry and `non_authorizing = true`.

A quote taken against the old version does not price the new one. Get a fresh quote whenever you change the workflow version, the parameters, the profile, the input snapshot, the output declaration or the limits.

If admission answers `REPLAN_REQUIRED`, the priced request drifted from what you submitted. Quote again and resubmit.

## Approve again only when the boundary moves

A quote never authorizes work, so approval stays a separate act on both versions.

Ask for a fresh approval in three cases:

- the new version changes what you may be charged
- it changes the destination a result is written to
- it needs a scope your current approval does not cover

Otherwise your existing approval continues to apply.

## Read the result the same way

The bundle layout does not change between versions. `result-manifest.json` is still written last, and it is still the only complete-bundle marker.

The namespaced result columns keep their names. If a workflow version changes its output schema, that change is on the descriptor and in the change entry. Check both before you alter your parser.

## What success looks like

You have a quote against the new version, an admitted job, a `SUCCEEDED` or `PARTIAL` status, and a bundle whose `result-manifest.json` is present.

Compare the manifest's counts with what you submitted, and compare a sample of results with the old version's output on the same input. Then move production traffic while the overlap window is still open.

## If something refuses

- `REPLAN_REQUIRED` — quote again, then resubmit.
- A refusal naming a field path — remove or correct that field and resubmit.
- A refusal naming an approval or a scope — approve it, then resubmit.
- A refusal naming capacity or budget — see [what each refusal class means](/docs/compute/reference/states) before you retry.

Every non-success carries a safe reason and a next action. Follow the next action on the response before changing anything else.