What Support and SLA Terms Change When You Migrate Providers

Almost all the attention an availability commitment gets goes to the number of nines. Almost all the risk is in the three clauses around it: what counts as downtime, what the commitment covers, and what you have to do to collect.

The four parts, and where the risk sits

Every service level agreement, whatever its length, is four things. A measurement definition that says how availability is computed. A target, the percentage. A remedy, what you get when the target is missed. And a claim procedure, what you must do to receive it.

The target is the only part that is easy to compare, which is why it is the only part usually compared. It is also the part that carries the least information, because two agreements with identical percentages can differ by an order of magnitude in what they actually promise, purely through the measurement definition. When you migrate, you are not moving from one number to another; you are moving between four clauses, and at least three of them will read differently.

How downtime gets defined

There are two broad styles and the difference matters more than the percentage attached to either.

An error-rate definition computes, over a billing month, the fraction of your valid requests that returned a qualifying error, and treats availability as one minus that fraction. It captures partial degradation — an hour where one request in five failed becomes real downtime. A service-state definition asks whether the service was up, usually as judged by the provider’s own monitoring, and tends not to register partial failure at all.

Then read the exclusions, which is where an agreement is won or lost. Common exclusion categories, each of which removes a class of failure from the calculation:

• Errors attributed to you. Requests that exceeded a documented rate limit, quota or size limit. This is the important one for model APIs, because rate-limit responses are a very common form of bad hour, and under this clause an afternoon of 429s can be zero downtime.
• Capacity or overload responses. A distinct status for “the service is temporarily unable to take this” may be excluded separately from ordinary errors. Ask explicitly whether it counts, because it is the failure mode you will actually meet.
• Beta, preview and early-access surfaces. Frequently excluded wholesale — which matters when the model you migrated to is newer than the endpoint it is served on.
• Scheduled maintenance, sometimes with a notice requirement and sometimes without a cap on how much of it there may be.
• Anything upstream — network, force majeure, third parties — and, in some agreements, failures of a dependency the provider itself buys.

A useful test when reading a new agreement: take your last three real incidents with your current provider, and work out whether each would have counted under the new definition. That converts an abstract comparison into an answerable question, and it usually produces a different ranking than the percentages do.

Scope, tiers and commitments

Scope is the clause most likely to change silently at migration, because it is expressed in the provider’s own product vocabulary. Things to establish:

• Per-service or per-model? An availability commitment on “the API” may say nothing about whether a specific model is served. A model that is unavailable while the API returns healthy responses for other models is a real failure that some definitions do not capture.
• Per-region or global? If you pinned a region for data-residency reasons, check whether the commitment is measured there or across the fleet.
• Which plan? Availability commitments are often attached to a paid tier, a committed-spend agreement, or a support plan purchased separately. Arriving on a pay-as-you-go footing during a migration and moving to a commitment later means running uncommitted for the riskiest period.
• What the commitment costs you to keep. Enterprise terms are usually bought with a minimum spend over a term. That has a direct migration consequence: moving volume away from an existing provider can breach a minimum you already signed, so the cost of a migration includes whatever shortfall clause applies for the remainder of the term. Establish the ramp-down and the notice period before you move traffic, not after.

What a credit is actually worth

The standard remedy is a service credit: a percentage of what you spent on the affected service in the affected month, applied against future invoices, capped, and usually stated as your sole and exclusive remedy. Three properties follow, and they are the reason to treat an availability commitment as a signal rather than as insurance.

It is bounded by your spend, not by your loss. If an outage costs you a day of transactions, the credit is a fraction of a month of inference bills, which will not be the same order of magnitude. It is paid in future service, so it is worth nothing if the incident is what makes you leave. And “sole and exclusive remedy” means the number is not a floor you can argue up from.

The practical reading: an SLA tells you what a provider is willing to be measured against, which is genuine information about their confidence. It does not transfer your risk. The thing that transfers risk is a second provider you can actually reach, which is why the engineering in draining traffic before a cutover is worth more than the clause, and why the library’s pages on testing fallback order belong in the same conversation as the contract review.

The claim procedure is an engineering requirement

Credits are almost never automatic. A typical procedure requires you to submit a claim within a window after the incident month, with evidence: dates and times, affected request identifiers, and error responses.

That has a concrete engineering consequence, and it is the reason this clause type belongs on a technical page. If you do not retain per-request identifiers and timestamps for at least the claim window, you cannot substantiate a claim, and the commitment you negotiated is unenforceable in practice. Retention has to outlast the window with margin, the identifiers have to be the provider’s — the id it returns on the response, not only yours — and they have to survive a migration, which is the subject of request id tracing across a migration.

Two smaller traps. The claim window is often short relative to how long it takes an organisation to notice a bad month, so the trigger for filing should be automatic from your own error-rate monitoring rather than a person remembering. And your error-rate measurement should exclude the same categories the agreement excludes, or your internal number and the provider’s will disagree and you will argue about arithmetic instead of about the incident.

Support terms are a separate document

Availability and support are usually governed separately, and the support terms are the ones you will feel weekly. The clause types to compare:

• Response versus resolution. Nearly all support commitments are first-response targets. A one-hour response target says nothing about when the problem is fixed, and no commercial support agreement commits to a resolution time for a novel bug.
• Severity definitions and who assigns them. This is the actual lever. If the highest severity requires production to be wholly unavailable, then partial degradation — the common case — gets a lower tier and a longer clock. Check whether you can declare the severity or whether the provider assigns it.
• Coverage hours and channels. Business hours in whose timezone, in which languages, through a ticket queue or a shared channel, with or without a named contact.
• What support covers. Availability and API behaviour, almost always. Model output quality, almost never. This matters more than it sounds: a model that quietly gets worse at your task is not an SLA event and is usually not a support case either, so your only defence is your own evaluation suite — silent model updates covers why. Migrating providers does not change that.
• Deprecation notice. How much warning you get before a model you depend on is withdrawn, and whether the notice period is contractual or a published policy that can change. This is the term with the largest engineering cost attached to it and the one least often negotiated.

Ask for all of this in writing during the evaluation, before the commercial conversation has concluded, because that is the only point at which the answers are cheap to obtain.