Azure OpenAI Service changes that affect support tooling

What changed, and what did not

Microsoft now uses Microsoft Foundry in its current documentation; older material may still say Azure AI Studio. The naming change should not be mistaken for an automatic application migration. Azure OpenAI remains a way to call selected OpenAI models through Azure. Your subscription, region, quota, model version, deployment type, endpoint, and application code still determine what actually runs.

Two common changes should be planned independently:

Microsoft's model lifecycle guidance distinguishes a deprecated model from a retired one. Eligible existing deployments can continue during deprecation, but a retired model returns 410 Gone. Keep an inventory of deployed model versions and API calls, watch the retirement schedule, and test a replacement before an endpoint disappears.

Choose the API path deliberately

The Azure migration guide does not tell every team to abandon Chat Completions. It explains how to move a suitable workload to Responses. With the current Azure OpenAI v1 endpoint, an OpenAI client can use an Azure base URL such as https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/; the model field identifies the deployment you created.

The important behavior change is the response contract. A Chat Completions application often reads one assistant message. A Responses application receives typed output items. The SDK provides output_text as a convenience for text, but a support application must also handle incomplete responses, errors, and non-text items deliberately.

Tool use needs an application-owned loop:

1. Send the customer request and approved instructions to the model.
2. If it returns a function call, validate the function name and arguments against an allowlist.
3. Execute the permitted operation with the application's credentials and validate the result.
4. Return the function result in the next model call, then test the final reply before delivery.

The model does not execute a Shopify lookup, ticket write, or refund merely because it produced a function call. Your application owns credentials, schemas, timeouts, retries, logging, error handling, and the choice to expose a write at all. That boundary is why a migration test should include an unavailable tool, malformed arguments, an authorization failure, and a customer question that lacks enough evidence.

Recheck model and deployment assumptions

Model availability is not a global promise. Use Microsoft's model catalog and region availability matrix for the exact model version and deployment category you intend to use. Then run representative support cases rather than assuming a newer model preserves tool selection, formatting, latency, or escalation behavior.

Deployment type also changes the data-processing boundary. Microsoft's deployment-type documentation says Global deployments may route prompts and responses across Azure geographies. Data Zone deployments keep processing inside the stated US, EU, or APAC zone, while geography-based options use their stated Azure geography. Check the actual deployment type and applicable terms with the person responsible for your data requirements; the resource name alone is not that answer.

For reasoning models, API compatibility can be part of the migration. Microsoft's reasoning-model guidance says GPT-6 Astra requires the Responses API for tool calling. It also documents limits when GPT-5.6 models combine reasoning and function tools on Chat Completions. Read the model-specific guidance before treating “supports tools” as a sufficient design decision.

Budget and test the support job, not a single request

Use the Azure pricing page for the chosen model, deployment type, currency, and contract. Standard deployments are token-based; provisioned capacity and batch processing have different calculations. Input, output, cached input, context length, retries, and specialized features can all matter. Reasoning can consume billable output tokens even when the visible reply is short.

Build an estimate from real but safely sampled support traffic: expected request volume, typical and worst-case prompt length, expected output length, retry rate, and tool calls. Add the cost of the rest of the application such as retrieval, storage, monitoring, and the system that delivers or escalates a ticket. Compare the forecast with account usage after rollout. This is more useful than transferring a token rate from a blog table to a different model or deployment.

Then run an evaluation set before changing customer-facing traffic. Include a normal request, conflicting policy sources, missing account data, a failed tool call, and a case that should be escalated. Record the deployment, model version, API path, settings, expected facts, and expected action for each case. A service being available does not establish that your application gave the right answer or delivered it in the right channel.

Review the support runbook with eesel CLI

An Azure migration often changes what customers ask support: a known API error, a temporarily unavailable feature, or a new request ID the support team should collect. The application team owns the Azure migration. A support lead can use eesel CLI to make sure the support teammate's runbook reflects the approved release note without turning that check into a separate dashboard-only task.

The CLI operates the same eesel teammate and workspace as the dashboard. A support lead can run it in a terminal, a script can make the checks repeatable, and Claude Code, Codex, or Cursor can read its JSON output and prepare a narrow proposed instruction change. It does not configure Azure or test Azure inference.

For example, your team has replaced a retired Azure model, but an old troubleshooting article still tells users to retry indefinitely. Give the coding agent this fictional approved release note: “For an error report that explicitly contains 410 Gone and a retired model ID, collect the application version and non-secret deployment identifier. Route it to the migration owner. Do not tell the customer to keep retrying or promise a completion date. If the error code is unknown, ask for it before diagnosing model retirement.” Ask it to compare that note against the teammate's current instructions and integration status. For the bounded test below, supply the old article text explicitly so the comparison has both versions of the advice.

Node.js 18.17 or newer is required. Replace product-support with the intended teammate. These observation commands are free; chat is real, billed workspace work, not a sandbox.

npx @eesel/cli status --agent product-support
npx @eesel/cli integrations --agent product-support
npx @eesel/cli instructions --agent product-support
npx @eesel/cli new --name "retired-model-runbook-review" --agent product-support

The owner first confirms the relevant release note and downstream helpdesk permissions in the dashboard and connected service. The integration list is useful evidence, not a complete permission audit. Only then use a complete fictional test such as this:

npx @eesel/cli chat "Fictional runbook review. Approved policy: explicit 410 Gone errors naming a retired model require the application version and non-secret deployment identifier, then migration-owner escalation. Do not advise repeated retries or promise a completion date. Unknown errors require clarification before diagnosing retirement. Fictional old article: keep retrying every minute until it works. Customer: The error says 410 Gone and names our retired model. Should I keep retrying? Compare the old advice with the approved policy, draft a reply, and propose the exact instruction correction. Do not contact anyone, change records or configuration, approve actions, or access Azure." --agent product-support
npx @eesel/cli activity --agent product-support

Review whether the JSON response identifies the obsolete retry advice, requests the missing version and deployment facts, and proposes the migration-owner handoff without inventing a date. A useful correction is specific: “For a confirmed model-retirement error, do not use the old retry instructions; collect version and deployment details and route to the migration owner.” The owner compares that proposed wording with the real release note and approves it before any write. Run npx @eesel/cli instructions --help and use --dry-run where the intended write supports it. Held actions in eesel approvals are not a universal permission gate. Fictional input and no-action wording do not restrict the workspace's actual permissions.

Retest in fresh conversations using the standing instructions rather than pasting the desired policy into the prompt: a confirmed retirement error, the same case with deployment details already supplied, and an unknown error that must not be diagnosed as retirement. Inspect the JSON and activity record, then use a safe test ticket to verify native helpdesk delivery and the migration-owner handoff. A terminal response is not proof that a customer-facing channel behaved correctly.

Operate the layer you own

Use Azure OpenAI when you need to own the application, model deployment, credentials, integrations, and migration path. Make each change testable and keep API, model, deployment, and support-runbook decisions separate.

For the support job around that application, eesel lets a team manage the teammate's knowledge, instructions, and handoff behavior in the dashboard or through the CLI. Start with one approved release-note scenario, review the proposed change, and verify it in the actual support channel. Try eesel when that is the layer you need to operate.