GPT-6 Astra migration on Azure: the GPT-5.6 Sol checklist

Point a working GPT-5.6 Sol integration at a gpt-6-astra deployment on Azure and one of three errors arrives before the model says a word: a rejected reasoning effort of none, a rejected temperature, or a tool call sent through Chat Completions. OpenAI's model guidance names those as the usual failures after the switch, and Microsoft's Learn pages confirm that all three apply on Foundry. Sol itself is going nowhere. Its retirement date on Foundry is 11 January 2028, so nobody is forced to move this quarter. But the capability gap we covered on Tuesday and the price gap from the launch-day analysis make the question live for every team with a Sol deployment. A model swap that touches the API surface, the effort dial and the cost per call deserves a checklist, and this one follows the six phases Microsoft published for exactly this job.

A voluntary migration, which changes the plan

Microsoft's model migration guide lists four reasons a migration starts: a model is retiring, a better model is available, cost or latency forces a change, or a capability gap blocks the product. Only the first comes with a deadline, and the retirement schedule puts all three GPT-5.6 variants at 2028-01-11. Astra is a "better model" migration, which means you set the pace and you can stop halfway.

The same guide is unusually candid about what halfway looks like: "Real migrations are often split-state: part of a workload runs on the new model while a latency-sensitive or higher-risk path stays on the old one, sometimes for weeks." For Astra that is the right end state, not a compromise. Long-context synthesis, long tool loops and computer-use tasks are where Astra earns its price. Interactive chat at conversational latency, anything bound to an EU Data Zone and anything that runs fine on a $4 input model can stay on Sol until the numbers say otherwise.

Phase 1: what breaks on day one

Start with the Learn reasoning page, revised 6 September, and the Foundry models page, revised 4 September. Between them they list every API-level difference that matters for a Sol-to-Astra move on Azure.

Two rows deserve a closer look. The max row settles a question we left open on Tuesday: the Learn page now states that max "works only with GPT-6 or GPT-5.6 models and the Responses API," so the fifth effort level is available on Azure and your routing table can use it. The configuration_update row cuts the other way. On OpenAI's platform you can change effort between responses without breaking the cached prefix; Azure "doesn't currently support mid-conversation reasoning effort changes" for Astra, so an effort change on Foundry means a fresh request and, if the prefix differs, a fresh cache write at $12.50 per million tokens.

There is also a clause on the models page that belongs in your test plan rather than your legal review: "In certain circumstances, Astra may apply enhanced safety controls when safety systems identify elevated risk," including "supplementing customer prompts with system-generated safety instructions." If replayed traffic scores differently on two runs, that is one explanation to rule out before you touch your own prompt.

Phase 2: Chat Completions to Responses, the actual diff

If your Sol integration already calls the Responses API, skip ahead. If it calls tools through Chat Completions at effort none, which is the workaround Microsoft documented for GPT-5.6, the migration is an API rewrite before it is a model swap. Microsoft's Responses migration guide for Python, dated June 2026, tabulates the changes, and they are mechanical but numerous.

The tool round trip is where most migrations stall. A follow-up request that still carries a Chat Completions tool message fails with unknown_parameter: input[N].tool_calls; a tool definition that keeps the nested shape fails with missing_required_parameter: tools[0].name. Both are listed in the guide's troubleshooting table, which is worth pinning next to the CI output. The minimal Astra call on Azure looks like this:

from openai import OpenAI

client = OpenAI(
    api_key=AZURE_OPENAI_API_KEY,
    base_url=AZURE_OPENAI_ENDPOINT + "/openai/v1/",
)

response = client.responses.create(
    model="gpt-6-astra-prod",          # deployment name, not model name
    instructions=SYSTEM_PROMPT,
    input=conversation_items,
    reasoning={"effort": "low"},       # none is rejected; start here
    tools=[{
        "type": "function",
        "name": "lookup_invoice",
        "description": "Fetch one invoice by number.",
        "parameters": INVOICE_SCHEMA,
    }],
    max_output_tokens=4000,
)

print(response.output_text)

Microsoft ships an Agent Skill and a scanner for this rewrite in the Azure-Samples repository. Installing the skill with npx skills add Azure-Samples/azure-openai-to-responses lets a coding agent do the mechanical edits; python migrate.py scan lists every legacy pattern in a repo, and a clean scan after the change is a useful gate even though the guide is explicit that it "is not a complete proof." Test mocks are the usual leftover: fixtures that return choices keep passing long after the production code has moved.

Phase 3: effort, prompts and the behaviours that shift

Microsoft's Adapt phase opens with one instruction: "Replay unchanged before you tune." Run your current prompts, tools and schemas against Astra with nothing changed except the deployment name and the removed parameters, and diff the outputs against a frozen Sol baseline. That isolates what the model changed from what you are about to change. Then adjust in this order.

Effort mapping. OpenAI's guidance is direct: "If you currently use none or minimal, start with low and compare results." Sol paths that ran at none for speed become Astra paths at low, which still reasons, so expect more output tokens and a higher first-token latency on those calls. Interactive paths cap at medium or high. The xhigh and max levels belong to queued work; our capabilities post has the independent latency numbers that make max unusable behind a spinner.

Initiative. Astra asks clarifying questions more often than Sol instead of assuming. For an agent that is supposed to finish a job, OpenAI recommends prompting the model to "bias towards action and carry the user's intended task to completion," and spells out the trigger: "When the user's prompt indicates a request for action, such as 'can you...', 'I want to...', 'help me...' and similar expressions, treat these as instructions to do the work." If your Sol prompt already contained a paragraph telling the model to stop guessing, test removing it; the two instructions now fight.

Output style. The same guidance page tells you to instruct Astra to write in clear, concise paragraphs, prefer active voice over lists, and avoid a named set of filler words including "delve," "foster" and "leverage." Customer-facing copy generated by Sol prompts may come back noticeably plainer. That is usually welcome, but a downstream template that expected bullet points will notice.

Refusals. The system card reports that Astra refused 91.5% of prohibited cyber requests where Sol refused 59%. Security tooling, vulnerability triage and anything that quotes exploit code in its inputs should be in the replay set, and refusals should be logged as a category rather than treated as errors. Microsoft's guide warns that "For agentic and workflow workloads, schema and tool-call work often outweighs prompt work." Tighten argument names and required fields before rewriting instructions.

Phase 4: cost on your own traffic, not on the price sheet

The Assess phase has one sentence every budget owner should read: "Reasoning tokens, cached input, and structured-output overhead can swing unit economics by 2x or more, so project monthly cost on historical traffic rather than list price alone." For Astra the list-price ratio is already large, and the replay tells you which side of it you land on.

Against the promo, Astra costs 2.5 times more on both input and output. A nightly document job of 500 files at 150,000 input and 5,000 output tokens each costs about $875 a night on Astra and about $350 on Sol at promo rates. Reasoning tokens bill as output on both models, so the replay's output-token count, not the list price, decides whether your real ratio lands above or below 2.5. Astra was measured producing a third fewer output tokens than the median model on the Artificial Analysis index run, which helps, and running xhigh where Sol ran none more than cancels it.

Batch is the missing discount. On OpenAI's own platform Astra runs at half price in Batch and Flex, $5 input and $25 output. The Foundry region table, last revised 4 September, lists neither Sol nor Astra under Global Batch or Data Zone Batch, so overnight jobs on Azure pay the full rate on either model. If a queued Astra workload only pays off at batch pricing, that is a first-party OpenAI conversation, with the residency consequences below.

Phase 5: rollout on Foundry, one deployment type at a time

Astra needs no access request. Microsoft removed the Limited Access wording on 4 September, and the Learn page now says only that some quota tiers require a quota request, while "Tier 5 and Tier 6 subscriptions have quota by default." Deploy it as a second deployment beside Sol in the same resource, because the rollout mechanics differ by deployment type and the guide's warning applies: "Rollback decisions forced by a deprecation deadline instead of by evidence are a warning sign you started too late."

• Global Standard. Available for Astra in every European resource region including Sweden Central. Weighted routing between the Sol and Astra deployments is your job: "Weighted routing between two deployments is implemented in your own gateway or application layer." An API Management policy that splits by percentage and by request type (queued versus interactive) is enough.
• Provisioned. Astra Provisioned Throughput exists in Global and US Data Zone since 4 September, the latter at a 10% premium. Provisioned deployments are never auto-upgraded, and "PTU capacity is model-agnostic and fungible across provisioned managed deployments," so PTUs move from Sol to Astra by redeployment, not by purchase. Confirm the throughput per PTU for Astra before assuming the same unit count covers the same traffic.
• Regulated paths. Where you cannot canary on live customers, run Astra in shadow mode on production inputs and compare offline. The guide names this pattern for financial and health data flows.
• Observation. Wire continuous evaluation on the Foundry Observability dashboard to a sampled slice of production traffic, with Azure Monitor alerts on the quality score, and keep the Sol deployment warm for about 30 days after the switch.

Phase 6, Retire, is the one teams skip. Delete the Sol deployment when the window closes, archive the evaluation runs, and update every document that names the model, including the processing records your data protection officer keeps.

The Swedish and EU angle

The region table decides how far a Swedish migration can go. As of its 4 September revision, Astra is listed under Global Standard and Global Provisioned for Sweden Central and the other European regions, and under Data Zone Standard and Data Zone Provisioned only in the Americas. Sol is listed in both EU Data Zone types. Every workload that was placed on an EU Data Zone deployment for a documented residency reason therefore stays on Sol, and the split-state migration Microsoft describes becomes the only compliant shape. When the EU zone arrives for Astra, it will carry the 20% premium that applies to the newer models, so re-run the cost table at $12 and $60 before moving those paths.

Going direct to OpenAI for the half-price Batch tier has its own EU footnote. OpenAI's guidance states that "GPT-6 Astra does not support service_tier: fast or service_tier: priority with EU data residency," so an EU-resident project on OpenAI's platform gets standard and batch processing only. That is fine for overnight jobs and a problem for anything that needed the fast tier.

One more thing for the governance file. The API migration is the deliberate route into Astra. The undeliberate routes, Copilot Cowork, Copilot Studio and GitHub Copilot, may already be delivering the same model to your users under OpenAI's subprocessor terms, as mapped in yesterday's post. A migration plan that lists the API workloads and ignores the four doors describes half the tenant.

The checklist

1. Inventory every Sol deployment with its type (Global Standard, Data Zone, Provisioned) and the API each caller uses. Flag every Chat Completions caller that sends tools.
2. Freeze a test set from captured production traffic before you deploy Astra. Capture is opt-in and never retroactive; start logging now if you have not.
3. Deploy Astra side by side in the same resource. Check quota tier; request quota if you are below Tier 5.
4. Move tool callers to Responses using the Azure-Samples skill or scanner. Fix test fixtures, not just app code.
5. Strip temperature, top_p, logprobs and effort none. Map none to low, and rename prompt cache retention if you set it.
6. Replay unchanged, then diff against the Sol baseline. Watch verbosity, clarifying questions, tool-call shape and refusals.
7. Adapt prompts: add the bias-toward-action instruction where the agent must finish, remove instructions that conflict with it, and tighten tool schemas before rewriting prose.
8. Project cost from replay token counts, including reasoning output. Decide per request type, not per application.
9. Route by weight and type in your gateway. Keep residency-bound paths on Sol's EU Data Zone until Astra has one.
10. Retire deliberately: delete the Sol deployment after the 30-day window, archive evaluations, update processing records and customer documentation.

Sol's retirement date is sixteen months away. That is enough time to migrate the workloads where Astra pays for itself and leave the rest where they are while the EU Data Zone catches up.