Set Your AI Service Exit Conditions Before Signing

Imagine selecting a generative AI service to help draft internal documents and routing an annual contract for approval. The trial produces good enough prose and the fee is within budget. But the proposal does not say “who will validate the model when it changes?” or “what can we take with us when the contract ends?”

Before signing, decide not only on current performance but also on the conditions for moving to another service. This article recommends first identifying which instructions, settings, and evaluation input examples accumulated in the business process the company will manage itself. Then include a small migration test in the procurement requirements.

Separate the decision to start using a service from the decision to continue

Japan’s Digital Agency has operated its internal generative AI environment, “Gennai,” since May 2025. Its expansion to other ministries distinguishes a large-scale deployment trial in fiscal 2026 from full use beginning in fiscal 2027. [1] The point to take from this case is to separate providing a usage environment from establishing the conditions for continued use. Private companies should likewise treat trial approval and long-term contract approval as separate decisions.

If you pin down the model, is there no need to prepare for change? Microsoft’s official documentation says Foundry models have retirement phases, and inference requests to retired models will fail. It also explains that a successor model may not be available in the same region. [3] These are specifications for Microsoft’s service and do not apply uniformly to every generative AI product.

For that reason, do not assume the contract period and model availability period are the same. Check each candidate and decide where retirement notices go, who makes the internal decision, and when to test alternatives.

Define “portable” for each type of asset

The first thing to create should be an inventory of assets to hand over during migration, rather than a product feature comparison. List instructions, processing steps, source materials, business terminology, output formats, evaluation inputs, and scoring criteria; record an owner and storage location for each. Do not assume everything should be moved outside the company; define what may be transferred at the same time.

Version 2.0 of the Digital Agency’s guidelines for procuring and using generative AI lists clear model-version information and design/implementation that considers ease of migration as basic items in its procurement checklist. By contrast, exporting chat history and registered prompts is an optional bonus item. [2] This article uses the government-oriented checklist as a reference for thinking about private procurement terms.

A response that “data can be exported” is not enough as a handover condition. Specify what can be exported, in what format, by when, and by whose action. Depending on the use, also decide whether to retain the mapping between attachments and their sources, the meaning of settings, and timestamps in history. Do not leave excluded fields blank; ask for the reason they are out of scope.

For example, with a system that summarizes applications, receiving chat history alone does not allow the same conditions to be recreated in a new environment if department-specific instructions or versions of referenced materials are unknown. Check whether the information needed to reconstruct the business process is complete, not just the number of exported files.

Rebuild one business process in another environment before signing

Do not turn the migration test into a contest to reproduce every feature of candidate services. Choose one process and rebuild it in another environment from the assets received. This reveals which settings are known only to the current provider.

Microsoft’s model migration process also recommends preparing representative inputs, expected outputs, and success criteria before choosing a destination, then holding them constant during comparison. [4] This advice concerns moving between models from one provider, but the approach is also useful for cross-service migration testing. The steps below are this article’s proposal for applying that approach to procurement.

First, the user department selects not only ordinary inputs but also examples with omissions and variations in notation. Then development retrieves the source settings and converts them for the destination. Finally, the business owner checks them against the original conditions. Instructions may be tuned for each model, but the scoring inputs and pass criteria should not change.

For the decision, prioritize whether required content is preserved rather than whether the text looks similar. For example, a summary of an application might need to retain amounts, deadlines, and unresolved points. Record the work required for tuning and information that could not be moved, then estimate the remaining work before finalizing the contract scope.

Decide whether to use proprietary features alongside migration costs

There are three options. First, use features of a particular product deeply. This is a strong option if you decide it can assemble the necessary capabilities quickly. However, estimate separately the cost of rebuilding proprietary settings, apart from initial deployment costs.

Second, restrict use to features shared across multiple products. This makes it easier to standardize specifications, but may require giving up proprietary features you want. The user department must decide how much business value it can forgo in exchange for portability.

Third, this article recommends managing business instructions and pass criteria internally while keeping product-specific connections and settings separate. The goal is not perfect compatibility, but knowing what must be rebuilt. However, maintaining settings in two places adds upkeep, so compare its cost with the option of relying on one product.

The comparison should include regular usage fees, asset export, settings conversion, revalidation, user communications, and any period of parallel use. Choose migration triggers—such as a maximum acceptable price, retirement of a required feature, or mismatch with internal usage conditions—and assign owners.

Avoid overengineering and close gaps in responsibility

This approach is unsuitable for a short trial when there are no business assets to preserve and no outputs to hand over at the end. There is no need to build a common foundation for multiple products in that case. Confirm data retention and deletion terms and set an end date for the trial.

For ongoing business use, do not place all migration responsibility on IT. A possible division is: procurement owns the handover scope and cost; the user department owns business acceptance criteria; development and operations own settings conversion and reconstruction. Include the contract reviewer and state which work falls under ordinary maintenance and which counts as additional work.

If you use a Forward Deployed Engineering (FDE) approach, working with customers from planning and prototyping through implementation and adoption, migration constraints discovered during prototyping should also be included in the deliverables handed to the buyer. Estimating only after deciding to migrate means the costs compared during initial selection were too narrow.

Practical implications

Recommendation 1: Attach an asset handover inventory to the request for proposal. Ask for export scope, format, excluded information, delivery timing, and owner.

Recommendation 2: Include a small migration test in pre-contract review. Rebuild one business process in another environment, identify missing required information, and estimate tuning effort.

Recommendation 3: Record why proprietary features were chosen and the conditions for leaving. Respect the decision to prioritize convenience while naming who receives change notices, who decides the migration budget, and who validates the business process.

References

1. Japan Digital Agency, “Government AI ‘Gennai’” (publication/update date unknown; checked 2026-09-21)
2. Japan Digital Agency, “Guidelines for Procuring and Using Generative AI to Advance and Innovate Government” (Version 2.0, updated 2026-06-12; checked 2026-09-21)
3. Microsoft, “Microsoft Foundry Models lifecycle and support policy” (updated 2026-07-24; checked 2026-09-21)
4. Microsoft, “Model migration process” (updated 2026-08-19; checked 2026-09-21)

This article was created with AI assistance and automatically reviewed before publication. Information checked on: 2026-09-21.