As enterprise AI moves from one-off questions into ongoing ticket, document and management workflows, switching providers means moving an entire business process. A successful text response establishes connectivity; continuity of work, explainable existing results and the effort needed to leave determine whether the enterprise has a practical choice. This is a durable engineering analysis, not a claim about a newly announced event. All numerical examples are constructed and are neither IDENIFE project results nor market quotations.
Similar interfaces leave migration responsibility with the application
In the Anthropic compatibility documentation consulted on October 18, 2026, response_format and tool strict are marked as ignored; structured outputs are available through a different, native API path.[1] This is a limitation of that integration route, not evidence that the model cannot produce structured results. It illustrates why an accepted request does not establish that every supplied constraint was enforced.
Google's Gemini compatibility documentation also retains an extra_body mechanism for provider-specific capabilities.[2] A common SDK can therefore conceal different parameters, response handling and capability boundaries. Check the actual model, interface and version in use rather than treating the word compatible as approval for every workflow.
Existing methods for enterprise LLM upgrades and business regression testing address whether a candidate better serves current tasks. A provider exit adds another question: after the old endpoint is disabled, where do files, historical state and failure evidence come from? The additional contribution here is to make those dependencies deliverable and testable engineering assets, rather than repeat model rankings.
Inventory dependencies before deciding what must move
Trace one operating workflow backward: where do business inputs originate, where are prompts and tool definitions stored, are files represented only by provider identifiers, can citations resolve to the original material, and what lets unfinished work continue? For each dependency, record its business owner, storage location, export method, rebuilding method, required permissions and estimated effort. A list of model names is insufficient.
Classify assets as directly portable, convertible, rebuildable or non-portable. Owned prompt templates may be exported with their versions. Provider file IDs should map to owned business document IDs and source files the organization is authorized to retain. A hosted index may need rebuilding. Actual APIs and data permissions determine the classification; complete export cannot be assumed.
Business state should identify confirmed inputs, authorization scope, completed tool actions, outcome receipts and the next pending step. Do not assume opaque internal model state has a universal representation. If another model cannot continue the original process, restart from an explicit business checkpoint or hand off to a person. Replaying a conversation must not silently repeat actions already executed.
Retaining only a provider conversation ID turns a switch into state reconstruction, while copying every log indiscriminately can increase exposure. Keep the information necessary for recovery and explanation, with retention limits, access controls and deletion propagation. Portability and data minimization need to be designed together.
Standardize necessary contracts while isolating native capabilities
Portability does not require erasing every provider advantage. Keep stable business contracts in the application: input materials, permitted tools, output fields, supporting evidence, human handoff conditions and spending limits. Isolate message formatting, stream events and native parameters in adapters. Use a distinctive native capability when it adds value, but document its substitute and rebuilding cost.
LiteLLM documents that unsupported common parameters raise errors by default, while an option allows those parameters to be dropped.[3] That is framework behavior, not a quality guarantee. For migration acceptance, this article recommends an explicit failure policy for essential constraints: block an unmet requirement rather than silently remove it to make a demonstration work.
Identify each workflow's minimum acceptable capabilities. Document extraction may require field validation and evidence locations; ordinary summaries may tolerate different wording; external execution must preserve authorization and reconciliation. If a candidate cannot satisfy an essential contract, narrow the migration scope. Retaining useful native features is compatible with acknowledging that some workflows are not yet portable.
An exit rehearsal must succeed without the old service
Create an isolated rehearsal environment using authorized redacted or constructed material, and freeze the inputs, acceptance rules and adapter versions. First restore new requests from the migration package, then test unfinished work. Disable the old provider endpoint in that environment, or explicitly deny it through access policy. Otherwise hidden file downloads and conversation reads can produce a misleading success. This does not require disabling a healthy production service.
Cover at least three states: a new task with no action performed, a task with a completed tool result but no final answer, and a task whose external action has an unknown outcome. The second should reuse a verifiable receipt. The third must query and reconcile the external system before continuing; if uncertainty remains, hand off to a person. Changing the model does not undo an order, message or write that already occurred.
Record business acceptance, asset completeness, recovery duration, manual steps and remaining dependencies separately. Do not merge import success with task success: every file might import while document revisions or citation relationships disappear. Preserve failed cases with reasons and accountable owners rather than submitting only a recording of the successful demonstration.
Reuse established business regression cases, but add a portability test: can another authorized engineer complete the migration from the instructions without live explanations from the original integrator? Hidden configuration known to one person is a personnel dependency. An export button without rebuilding instructions is a delivery dependency. Both affect actual readiness.
Compare total migration cost, not only inference prices
Separate one-time migration, temporary parallel operation and continuing operation after the switch. Migration includes adaptation, data conversion, evaluation and human acceptance. Parallel operation includes calls to both providers and necessary extra review. Continuing costs include inference, adapter maintenance, state storage and additional human work. Avoid counting costs that would exist anyway twice.
Consider a constructed arithmetic example. The current service costs RMB 30,000 per month in inference, the candidate RMB 20,000. Migration costs RMB 120,000 once, with RMB 4,000 in additional monthly maintenance and review. Ignoring other differences, net monthly savings are RMB 6,000 and the simple payback period is 20 months. With only 12 months of foreseeable use, RMB 72,000 in cumulative savings would not cover the migration investment. These are assumptions, not vendor prices or a financial forecast.
If migration removes an unacceptable service dependency, a long payback period alone should not reject it. Separately describe the interruption or capability gap the organization needs to avoid, acknowledging that its probability may be unknown. Conversely, do not invent an enormous outage loss to make any migration appear worthwhile. Present cost savings and continuity reasons separately so the decision can be reviewed.
Portability has a maintenance cost of its own. Sustained dual-provider operation needs repeated testing and permission management. Infrequent, human-reviewed assistance may only justify exportable configuration and periodic rebuilding exercises. Consequential tasks or short recovery deadlines are stronger candidates for prevalidated capacity and a complete standby path.
Accept a migration package, not just a promise
Make the technical delivery checklist include versioned prompts and tool contracts, mappings between business documents and provider identifiers, necessary state and outcome receipts, rebuilding procedures, known non-portable assets, and an exit rehearsal record. Use formats the team can inspect and maintain. Possessing files does not automatically provide the knowledge required to interpret them.
Make procurement discussions concrete: what outside cooperation does an exit require, how will relevant data be obtained and deleted, and who owns rebuilding and acceptance? Confirm export functions, service periods and migration assistance against the actual product, written agreements and demonstrated evidence. This article supplies engineering acceptance criteria, not a substitute for reviewing a specific contract.
Start with one well-bounded workflow that people can take over, measure the effort, and then decide whether to expand. The final decision record should state the verified scope, non-portable assets, evidence behind the recovery-time estimate, ongoing ownership and triggers for another rehearsal. The useful outcome is an executable choice, rather than an ever-longer list of supported model names.