Haiku 5.5 migration checklist

A Haiku 5.5 migration should produce two kinds of evidence: the new route accepts your application's requests, and the resulting answers still satisfy the work those requests represent. Changing the model identifier demonstrates neither by itself. Preserve the old behavior long enough to compare it with the replacement and to recover when a regression appears.

Start with a request inventory rather than a repository-wide text replacement. A production application may call the model from interactive chat, background extraction and a reporting worker, each with different defaults. One successful chat example does not establish compatibility for all three paths.

Inventory the Haiku 5.5 migration surface

List each calling module, provider route, prompt family, output format and downstream consumer. Include middleware that adds parameters automatically. Record whether the caller expects plain text, tool calls or structured records, and whether it stores provider response objects for use in later turns.

Inspect configuration outside source code. Deployment variables, dashboard-managed settings and job payloads can preserve an old model ID after the main adapter has changed. Search for aliases as well as exact names, but review each match before changing it; historical records and comparison fixtures should usually retain their original identifiers.

Create a migration manifest with an owner and acceptance test for every live call path. This makes the scope reviewable. A forgotten nightly worker should not become the first place you discover that a shared SDK setting is incompatible with the new model.

Separate compatibility from quality

Use the official migration guide as the authority for model-specific request changes. It identifies changes around thinking configuration, sampling, assistant prefill and response handling. Audit the actual serialized request, not only the object passed into your local wrapper.

For a Haiku 5.5 migration, first establish a minimal accepted request on the intended provider. Then restore tools, output schemas and conversation history one feature at a time. This order narrows failures: a rejected field needs a protocol correction, while an accepted but incorrect answer needs task evaluation.

Keep the old prompt unchanged during the first quality comparison where compatibility permits it. If a prompt change is necessary, record that as a separate variable. Otherwise a better answer may be credited to the model when the real cause was a clearer instruction or a smaller source document.

Recount representative requests

Do not carry old token counts into the new cost model. Tokenization can differ between models, and a prompt near a capacity or pricing boundary deserves fresh measurement. Count the complete request, including history and tool definitions, rather than only the visible user message.

A Haiku 5.5 migration cost sample should include short routine tasks and longer outliers. Averages alone can hide a document-heavy workflow that behaves differently from the common case. Keep each source fixture and request shape so later measurements can be compared on the same material.

Use actual returned usage for completed requests and the appropriate official rate version for estimates. Preserve cache categories and any provider-specific accounting distinctions. Do not multiply an old total-token number by a new advertised rate and call that a measured saving.

Review the response adapter

Select content blocks by type rather than assuming the first block contains the final answer. Preserve completion status and usage in your normalized result. A nonempty text field is not sufficient evidence that a request completed successfully or that the result meets the application's schema.

During a Haiku 5.5 migration, test empty text, output-limit stops, refusals and tool-use responses explicitly. Those cases often bypass the happy-path parser and reveal assumptions carried over from the previous model. Keep provider errors separate from task-level rejection so operators can choose an appropriate recovery action.

Do not discard response information merely to preserve an old string-only interface. Add the minimum structured result your application needs, then adapt existing consumers deliberately. A thin response wrapper can preserve status and traceability without turning the migration into a broad rewrite of unrelated modules.

Audit stored conversations

Old conversations may contain provider-specific blocks or patterns that a new route cannot replay unchanged. Examine a few representative histories, including tool calls and interrupted turns. Do not assume that every stored assistant message is equivalent to plain text that can be copied into a new request.

Define a transition policy for existing conversations before rollout. You might keep active conversations on their original route, start a fresh conversation with a user-approved summary, or migrate only histories that pass a compatibility check. The correct choice depends on your product's promises and the provider's documented constraints.

For Haiku 5.5 migration records, retain the serving model and provider per attempt. A conversation can legitimately span configurations, but its audit history should not be rewritten to claim that every old answer came from the newest model. Preserve original usage and rate versions for the same reason.

Build a regression set from actual failure risks

Choose anonymized or synthetic cases that exercise your application's difficult boundaries. Include missing information, contradictory sources, long inputs and outputs requiring exact identifiers. Add examples from previous incidents when they can be represented without retaining customer secrets.

Score the result that matters to the user. For classification, inspect category errors; for extraction, inspect field support; for summarization, inspect omissions and invented commitments. A generic preference score can overlook the one numeric mistake that makes a document unusable.

Repeat borderline cases in the Haiku 5.5 migration evaluation. A single success on a difficult fixture is weak evidence of stable behavior. Keep both accepted and rejected outputs so a reviewer can inspect why the score changed, rather than trusting a summary percentage without examples.

Roll out through a reversible route

Use a configuration boundary that can send eligible new operations to the new model without editing unrelated application code. Start with a limited, well-understood task family. Record which configuration served each operation so support can identify the affected group if a regression appears.

Avoid duplicating paid requests to production providers merely to compare them unless that experiment is explicitly authorized and budgeted. Offline fixtures and a controlled evaluation account can establish much of the integration behavior first. Real traffic experiments require their own privacy and spending decisions.

A Haiku 5.5 migration rollback should affect future eligible work while preserving completed records. Do not delete answers or rewrite usage history to make the rollback look clean. Decide separately what happens to operations already running, because cancelling them may create ambiguous completion and accounting states.

Watch the first operating period

Monitor invalid-request frequency, incomplete responses, acceptance rates and queue age after rollout. Compare like-for-like task groups rather than the entire application's changing traffic mix. A spike in short requests can make average latency look better even while long-document users experience a regression.

Track support issues with configuration context. A report that "the answers changed" becomes actionable when tied to a prompt version, source revision and serving model. Preserve enough diagnostic evidence to reproduce the issue without making raw private content broadly available in operational logs.

Do not declare the Haiku 5.5 migration finished solely because the deployment is healthy. Completion means the intended callers have moved, their acceptance tests pass, recovery behavior is understood and the old route is retained or retired according to an explicit decision.

Record the Haiku 5.5 migration decision

Record the request changes, evaluation scope, remaining limitations and rollback instruction in one maintained document. Link the detailed fixtures rather than copying large response dumps into the release note. Future maintainers need to know what was tested and what was intentionally left unchanged.

For a pricing-led decision, pair this checklist with Haiku 5.5 vs 4.5. For a rejected request, use the 400-error checklist. A successful Haiku 5.5 migration leaves the application easier to diagnose because model choice, request compatibility and task quality are recorded as separate decisions.