Systems and Workflows
Claude Sonnet 5.5 Migration Checklist for Existing Workflows
Use this route-by-route checklist to verify account access, context, settings, fallbacks, and handoffs before moving a workflow to Sonnet 5.5.
On this page
- Define the workflow that needs approval
- Save the current route before changing it
- Check access where the work actually runs
- Decide whether 1M context is a requirement
- Record effort instead of assuming a default
- Check thinking-off workflows before moving them
- Preserve model identity when a safeguard intervenes
- Check retention and account handoffs separately
- Put the evidence on a route card
- Apply the same questions to different routes
- Run the preflight in an order that exposes blockers
- Approve only the route the team observed
Short answer: approve the switch one workflow and provider route at a time. Anthropic names the API model and lists the product surfaces, but those announcements do not confirm your account has the right model, context option, settings, fallback behavior, or handoff.
An independent evaluation adds a reason to record effort and usage. Artificial Analysis reported unusually high output-token use at max and a benchmark task cost about 50% higher than Sonnet 5. It used a pre-release model with a structured-output issue later fixed for public release. Your route may differ, so treat the result as a reason to measure after migration, not a bill prediction. Our Sonnet coding-agent cost analysis covers that separate decision.
Define the workflow that needs approval
Start with one job your team already gives to Sonnet. Describe the route from its usual input to a reviewed result. Where does the request begin? Which provider and account receive it? Which tools may the model use? Who reviews the output, and what happens when the work is accepted or rejected?
A coding route might take an issue, inspect approved repository files, propose a patch, and send that patch through a targeted test and scope review. A document route might take source material and a template, then send a draft to an editor. These are examples of reviewable workflows, not accounts or results Rise has observed.
State the migration requirement in one sentence. A hypothetical coding team might write: “This route must accept its usual issue, use approved repository tools, return a reviewable patch, and retain any model fallback notice with the run.” Each part gives the team something it can check. “Upgrade to Sonnet 5.5” does not describe what must keep working.
Separate requirements from appealing features. If normal inputs fit within the route’s existing usable context, the listed 1M option may be interesting without being necessary for approval. If a session never crosses accounts, account handoff behavior need not delay that route. Another workflow might depend on both. Decide what the work actually needs before turning the announcement into a checklist.
This article addresses readiness. A separate question is whether Sonnet 5.5 finishes accepted work faster or at a lower total cost than Sonnet 5. Anthropic reports performance and task-cost gains in its testing, but a migration preflight does not measure either outcome for your team.
Save the current route before changing it
Record the provider, product surface, account or organization, requested model, effort setting, thinking setting, context option, connected tools, and approval path. Identify which settings are explicit and which the product supplies by default. If you cannot establish a field, mark it unknown. Guessing the old configuration makes a changed result difficult to explain later.
Keep a representative input and the existing acceptance check. For a bug fix, that might mean the starting repository state, a reproducible failure, a targeted test, and the reviewer’s rule for unrelated edits. For a document, retain the source material, template, required sections, and editorial criteria. Apply the same standard to the migrated result. Otherwise the new route may appear successful because its output received an easier review.
Include the normal retry and escalation rules. If the current coding route allows one agent attempt before a person takes over, write that down. If revision is part of a document route, record when and why an editor asks for it. A new route that reaches acceptance only after extra attempts may still be useful, but the team should be able to see that its operating pattern changed.
The baseline need not inventory every product preference. It needs enough detail to answer two questions: Did the routes receive comparable work, and which setting or approval step changed? A short record that answers those questions is more valuable than an exhaustive form nobody maintains.
Check access where the work actually runs
Anthropic says Sonnet 5.5 is available across its platforms, including Amazon Web Services, Google Cloud, and Microsoft Azure. It names claude-sonnet-5-5 for developers using the Claude Platform. The Claude Code release notes describe Sonnet 5.5 as the default Sonnet model on the Anthropic API. That last statement does not establish the default on every provider, product surface, or account.
Check selection on the route the team intends to operate. If development and production use different providers or accounts, check each required route. Seeing the model in an individual session does not establish access through a team’s cloud deployment. Seeing its name in a menu does not establish that a request with the workflow’s normal permissions will complete.
Keep three kinds of evidence separate. “Anthropic announced availability” is a published product statement. “Our account offers this model” would be an account observation. “This run was handled by this model” would require evidence from the run or provider. The first supports starting a preflight. The later findings support a decision about the team’s own route.
If selection fails, record the provider, account context, requested ID, and observed response. Treat that as an access finding. A model that did not run has not failed the workflow’s quality check. If entitlement or deployment status remains unclear, leave access pending rather than filling the gap with a broad launch claim.
Decide whether 1M context is a requirement
The v2.1.284 release notes list 1M context for Sonnet 5.5. They do not verify that a particular plan, provider, region, account, or workflow has the option enabled.
Begin with a normal job. Does the route need to supply a large repository view, lengthy source documents, or a continuing conversation that exceeds its current usable context? If normal inputs fit, extended context may remain optional. If recurring work depends on a larger window, make it an explicit requirement and save a representative input that shows why.
On the intended route, record the required option as available and configured, unavailable, or unchecked. If it is unavailable, the team can defer that route or redesign how it supplies information. Splitting a document, retrieving files in stages, or shortening a conversation may be sensible, but each changes what reaches the model. Review the revised process as a new route rather than calling it an unchanged migration.
Capacity and acceptance are separate checks. An input can fit while the resulting patch fails a test or a document omits a required point. The context check establishes whether the route can supply the intended material. Its usual reviewer still decides whether the work is acceptable.
Record effort instead of assuming a default
Anthropic states that Claude Code and Claude apps default to Medium effort, while the Claude Platform defaults to High. Anthropic describes lower effort as faster and less token-intensive for routine work, and higher effort as allowing longer reasoning and checking. Those are published product descriptions, not observations from your workflow.
Find out whether the existing route specifies effort or inherits a default. Record the intended setting after migration and confirm what the new route uses. A workflow that changes product surfaces can change effort at the same time as its model. If both change, a different output cannot be attributed to the model alone.
A known setting matters more than one universal setting. A routine document route and a complex code review route can have different reasons for their choices. The owner of each should be able to explain the configuration and judge the result against that route’s existing standard.
A later experiment might compare Sonnet 5 and Sonnet 5.5 under closely matched supported settings. The migration preflight asks whether the complete setup the team intends to operate works. Some records serve both questions, but approval of a route is not automatically a controlled model comparison.
Check thinking-off workflows before moving them
Anthropic’s Sonnet 5.5 announcement gives a specific migration instruction: users running Sonnet with thinking off need to switch to the new between_tools setting before moving to Sonnet 5.5. Anthropic says the setting keeps upfront thinking off and points readers to a migration guide. The captured announcement does not provide configuration steps for every application or establish how a particular account behaves.
First determine whether the current route runs with thinking off. If it does, identify the product surface and the behavior the route depends on. Consult the applicable product documentation for the configuration change, record the old and intended settings, and check the result on the actual route. If the current thinking setting cannot be established, leave this requirement unresolved until it is inspected.
Review the workflow, not only its final wording. A tool-using route needs to show that it can still call approved tools, follow the expected handoff, and return a result its reviewer can assess. A plausible answer that skipped a required tool step does not establish that the migration preserved the route.
If the workflow never ran with thinking off, mark this condition not applicable and say why. That status differs from passed: there was no related configuration change to verify. Clear statuses keep the preflight focused on the requirements that belong to the job.
Preserve model identity when a safeguard intervenes
The requested model and the model handling a request may differ. Anthropic says higher-risk cybersecurity requests can visibly fall back from Sonnet 5.5 to Sonnet 5, while routine software development is generally unaffected. The captured announcement does not identify how a particular prompt will be classified or how an individual fallback will be billed.
For a route that may encounter this safeguard, decide where to retain the requested model, any exposed handled-model information, and a visible fallback notice. A fallback result may still meet the team’s quality standard. Its provenance matters because that result cannot be counted as a clean Sonnet 5.5 run. If the route specifically requires Sonnet 5.5, define fallback as a separate outcome before reviewing outputs. If either model is acceptable, record that rule and preserve the model information anyway.
When the handled model cannot be confirmed, mark attribution unresolved. Writing style, apparent quality, or the absence of a noticed warning does not prove which model ran. If the team later evaluates charges, use the provider’s usage record before assigning a cost to a fallback. The captured announcement supplies no billing rule for a particular request.
A routine bug-fixing route and a security review route may reach different decisions after a fallback. Apply each route’s stated requirement. Do not assume every coding request will trigger the safeguard or that none will.
Check retention and account handoffs separately
Anthropic says Sonnet 5.5 is available with zero data retention, as were Opus 5.5 and Sonnet 5. Availability does not establish that a particular account or provider route has that arrangement active. If the workflow requires it, confirm the applicable terms and configuration in the team’s own account and policy records before approving that route.
The announcement also describes expanded preserved thinking. Anthropic says Claude’s thinking cannot be decoupled from the account that created it and directs users who move conversations between accounts, including account switches during a Claude Code session, to its documentation. The captured announcement does not show how a particular handoff behaves.
Map the account boundary, if one exists. Does one person start a session another account must continue? Does an automation create work for a different account to resume? Identify what must remain usable after the handoff, consult the applicable documentation, and check the intended route. A copied transcript alone would not establish that the required session can continue as expected.
Give retention and handoff separate statuses. A single-account route may mark handoff not applicable while its retention arrangement remains unknown. A cross-account route may confirm retention but still need a portability check. Combining them into one data-handling checkbox would conceal the requirement that remains open.
Put the evidence on a route card
A migration record should identify what the team approved and why. The following fields form a proposed route card, not a record Rise has completed:
- Route and reviewer: What to record: The workflow, its responsible reviewer, and the decision it supports
- Starting state: What to record: Provider, surface, account context, model, settings, tools, and acceptance rules
- Intended state: What to record: Provider, surface, account context, requested Sonnet 5.5 ID, settings, and required capabilities
- Representative work: What to record: Saved input, starting state, permitted tools, and expected handoff
- Model evidence: What to record: Selection result, requested model, exposed handled model, and any fallback notice
- Review result: What to record: Existing quality checks, scope review, retries, and reviewer decision
- Open conditions: What to record: Unknown access, configuration, context, retention, or handoff requirements
- Decision: What to record: Proceed, defer, or revise the route, with the reason and date of the check
A route card prevents a narrow result from becoming an organization-wide claim. If a colleague sees that one route passed on one provider with one effort setting, they can tell what was approved. If the account, provider, or required handoff changes later, the record identifies which observations need another look.
An unknown field is useful information. It directs the next check and prevents an unchecked requirement from quietly becoming a pass. The card should be short enough to maintain and specific enough that another reviewer can understand the decision.
Apply the same questions to different routes
Consider a hypothetical team with two existing Sonnet workflows. A document route drafts from a fixed template in one account. A repository route handles some security-sensitive reviews, sometimes needs extended context, and hands sessions between accounts. No access check, model run, or migration is assumed in this example.
- Model access: Single-account document route: Confirm selection on its document surface and account; Cross-account repository route: Confirm selection on its repository provider and every required surface
- Context: Single-account document route: Check whether normal source material fits; treat 1M as optional if unnecessary; Cross-account repository route: Confirm the context option required by normal repository inputs
- Effort and thinking: Single-account document route: Record actual settings and any applicable thinking-off change; Cross-account repository route: Record actual settings and any applicable thinking-off change
- Safeguard attribution: Single-account document route: Retain model identity if relevant to its requests; Cross-account repository route: Retain the requested model and any visible fallback with each review result
- Account handoff: Single-account document route: Mark not applicable if work stays in one account; Cross-account repository route: Check required session behavior across the accounts involved
- Retention: Single-account document route: Confirm the arrangement if document policy requires it; Cross-account repository route: Confirm the arrangement if repository policy requires it
- Output acceptance: Single-account document route: Apply existing template and editorial criteria; Cross-account repository route: Apply existing code checks and patch-scope review
The document route could be ready while the repository route remains pending. A successful document review says nothing about the repository route’s context requirement or account handoff. The reverse is possible too. The table predicts neither outcome. It shows why one organization-wide “migrated” label would hide the conditions that matter to different work.
Replace each question with an observation only after checking the intended account and route. Do not fill an unchecked cell with a product announcement. Published availability and observed access answer different questions.
Run the preflight in an order that exposes blockers
First, confirm selection on the intended account and provider. If that fails, a successful response on another surface cannot approve the original route. Next, confirm required context, effort and thinking settings, retention arrangements, and account handoffs. These conditions establish whether the route under review is the one the team plans to use.
Then submit representative work under the route’s approved tool permissions. Keep the input, configuration, output, and any model or fallback information the product exposes. Apply the acceptance standard saved from the existing workflow. For a patch, that means the agreed behavioral check and scope review. For a document, it means its required content, template, and reviewer decision.
Assign each requirement one of four statuses: passed, failed, unknown, or not applicable. Passed requires evidence from the intended route. Failed identifies a requirement the route did not meet. Unknown means a required check remains open. Not applicable means the condition does not belong to this route, with a reason. Several passed checks and one unknown essential requirement do not add up to an overall approval.
If the route fails, identify the failing condition before changing several settings at once. An access failure calls for an access or configuration investigation. A tool handoff failure calls for a workflow check. A patch that violates scope calls for quality review. Calling all three model quality failures would make the next action harder to choose.
Attach the decision to the provider, account context, settings, representative input, and reviewed result. Someone who did not watch the preflight should be able to tell exactly what was checked. The record also provides a baseline when a capability, setting, or policy changes.
Approve only the route the team observed
Proceed when the route’s required access, configuration, handoffs, model attribution, and output review have been checked and the result meets its existing standard. Defer when an essential entitlement, context option, thinking setting, retention arrangement, or account handoff remains unknown. Revise the route when the intended setup cannot meet a requirement and the team has another process worth reviewing.
A completed preflight supports a limited conclusion: one specified workflow on one specified account and provider configuration met its migration requirements. It does not establish readiness for every Sonnet workflow. It also does not verify Anthropic’s reported speed or task-cost gains. Those require a separate comparison of accepted results, time, usage, charges, and correction work.
Anthropic’s September 28 announcement and the Claude Code release notes provide the published starting facts. Your team’s route-specific observations supply the approval evidence. Move the workflow whose requirements you actually checked, and leave other routes pending until their own conditions are resolved.
Checked for this article
Sources
Keep going
Related notes.
Systems and Workflows
Should Your Team Build an Internal App with Copilot Code?
Microsoft says Copilot Code can build internal apps from natural-language requests. Here is how to decide whether your team needs one and what to verify before live use.
Read the article
Systems and Workflows
How to Turn Notion Into a Live-Updating CMS, CRM, and Database
A maintainable architecture for using Notion as a working source while synchronized tools power portals, apps, and structured views.
Read the article
Automation and Agents
Claude Sonnet 5.5 Coding Agent Costs: Is Switching Worth It?
Anthropic claims up to 30% lower task costs, while one independent benchmark found higher costs at max effort. Compare the evidence and measure cost per accepted coding task.
Read the article