Could your business keep working if you changed AI vendors?

An AI vendor exit plan is the set of assets, permissions, operating instructions and tested recovery steps that lets your business continue a workflow when its provider changes. It should exist before the workflow becomes essential. The useful test is whether another qualified operator can run a representative case, resolve an exception and prove completion using the handover materials.

A folder of exported files is only one part of that test. A workflow may depend on customer-specific mappings, undocumented commercial rules, a staff member's account, a supplier portal and the incumbent operator's judgment. Losing any of these can interrupt work even when the code has been delivered.

This matters whether you buy software, build internally or commission a managed service. Different arrangements carry different responsibilities, but none removes the need to know how the business continues. This guide offers an operational planning method, not a claim that every platform can be migrated without rebuilding.

Start with the business outcome that must survive

Write the finished state in business terms. For an order workflow, that might be a verified ERP draft linked to the original purchase order, with unresolved lines assigned to a named specialist. It is not simply that a model produced JSON or a flow reached its final step.

Then identify the operating boundary: who sends the input, which systems supply facts, which actions are permitted, who approves exceptions and where evidence is retained. Include the manual fallback. A sales team that can continue taking orders with a controlled queue has a better continuity position than one that depends on an unavailable automation dashboard.

Prioritize by business interruption. A weekly internal summary and a daily customer-order intake do not require the same recovery timetable. The owner should specify how much delay is tolerable, which work can wait and which communications customers need during an interruption. Avoid calling a workflow critical without identifying the actual consequence of a missed cycle.

The NIST AI Risk Management Framework playbook discusses contingency processes for third-party failures, continued monitoring and decommissioning. That supports treating continuity as a lifecycle responsibility; it does not prescribe one universal exit checklist for every business. NIST AI RMF Playbook: Manage

Inventory five kinds of dependency

A useful inventory follows a real case from input to completion. Record every dependency encountered, then distinguish the asset from the account or permission needed to use it. A spreadsheet of customer aliases may be exportable while the connected ERP access remains tied to a vendor-controlled identity.

This distinction prevents a common procurement error: assuming ownership of a deliverable means freedom from every technical dependency. Your company may own a rulebook but still need to implement it in another tool. Conversely, an ordinary commercial platform can be manageable if the rules, records and recovery process remain understandable.

Keep the inventory proportional. It does not need every internal implementation detail. It does need enough information to rebuild or operate the agreed business capability without rediscovering its most important assumptions under pressure.

Ask what an export actually contains

“Export supported” is the beginning of a technical discussion. It does not establish that the export can be imported into an unrelated product or executed without additional configuration. Ask for the exact format, what it excludes, the destination it supports and a demonstration using your representative workflow.

Microsoft documents package export and import for non-solution Power Automate flows. It also distinguishes those packages from Dataverse solution packages and recommends solutions for application lifecycle management. The formats are not interchangeable. This is a concrete example of why the word “export” needs qualification. Microsoft: Export and import a non-solution cloud flow

For solution-aware flows, Microsoft's guidance discusses associated components such as connection references and environment variables. It also notes that managed solutions cannot be exported. These are platform-specific constraints to verify during design, before assuming that a later handover will be a simple download. Microsoft: Export a solution-aware cloud flow

Separate portable knowledge from platform implementation. A decision table describing when an order needs approval can be documented independently. A connector's retry behavior, proprietary orchestration step or platform-specific credential reference may require reconfiguration or replacement. State that rebuilding work honestly in the exit estimate.

A strong delivery demonstration therefore includes both the export and a clean-environment restoration. If restoration requires undocumented intervention by the original engineer, capture that intervention as a dependency to resolve.

Keep business rules and exception history understandable

Prompts alone rarely describe the whole operating policy. A prompt may refer to a knowledge base, rely on a hidden default or assume that someone has already checked the customer's commercial terms. The replacement operator needs the authoritative rules and the order in which they apply.

Document approval thresholds, prohibited actions, mapping ownership and the response to missing or conflicting facts. Include a small set of redacted examples showing a correct completion, a clarification request, a rejected action and a recovered failure. Label each expected result and explain why it is correct.

Preserve the unresolved exception queue as part of the handover. An exported workflow can be technically complete while dozens of customer cases have no new owner. Each open case should identify its current state, outstanding decision, supporting evidence, next action and accountable person. Reconcile that queue at an agreed cutover point.

Also distinguish operational evidence from unrestricted data copying. Not every historic attachment must move to every replacement provider. The business should define which records are necessary, who may access them and how retention or deletion obligations are handled with the responsible advisers. Keep the continuity plan aligned with those decisions instead of using migration as a reason to duplicate everything.

Transfer access without creating a second uncontrolled operator

The access handover has two separate jobs: enabling the new operator and retiring access that is no longer needed. Test the first before triggering the second. Removing the incumbent's only working connection prematurely can turn an orderly transition into an outage.

Create an access register that names the resource, business owner, identity type, permitted scope, credential rotation method and revocation procedure. Record references to secrets in an approved secret manager rather than placing secret values in the runbook. Include webhooks and scheduled jobs; these can continue acting even when a person's dashboard access has been removed.

Different authorization mechanisms require different actions. GitHub's documentation distinguishes a user's authorization of a GitHub App from its installation on an account or organization. An organization owner cannot revoke a user's authorization on their behalf, but uninstalling the app prevents its access to that organization's resources. Treat this as a reminder to verify each system's actual access model. GitHub: Reviewing and revoking authorization of GitHub Apps

At cutover, establish which operator may perform live actions. Where both systems temporarily run, make one read-only or use another explicit control against duplicate writes. A transition period should never rely on the hope that two scheduled processes will avoid the same case.

Fictional USD example. Monetary assumptions in this guide are illustrative US-dollar amounts, not quoted prices, measured results or exchange-rate conversions. The currency does not imply a US tax or legal setting.

Price the exit as a scenario, not a surprise

An exit estimate should include more than the cost of moving files. The following example is entirely synthetic. It illustrates how to make transition work visible; it is not a Looqus price, customer result or estimate for a particular platform.

Assume a modest workflow needs 24 engineering hours at USD 250, 16 operations hours at USD 120 and eight business-owner review hours at USD 200. Allow USD 1,800 for temporary parallel infrastructure and subscriptions. The modeled transition cost is USD 11,320.

If a proposed replacement saves USD 1,000 a month at comparable scope and quality, this modeled transition alone takes 11.32 months of savings to recover. That excludes interruption costs, contract notice charges and other differences that must be investigated separately. It also assumes the savings persist and the replacement does not increase exception handling.

Internal review time is an economic cost even when it does not create a new cash payment. Show cash expenditure and staff capacity separately when making the final decision. A change may still be justified by reliability, control or service quality; avoid presenting those benefits as precise cash savings without evidence.

Rehearse the handover before the relationship ends

Use a representative, bounded exercise while the incumbent can still answer questions. Select one ordinary case, one ambiguous case and one failure requiring recovery. This is a practical readiness exercise, not sufficient evidence of performance across the full production distribution.

Have the proposed receiving operator work from the handover package. Check whether they can find the governing rule, access the approved systems, produce the expected result and locate the evidence. Record every intervention needed from the incumbent. The exercise should reveal missing knowledge rather than reward a polished demonstration.

Test restoration in an appropriately isolated environment where possible. If testing in a live system is necessary, agree the permitted actions, approvals and containment beforehand. Reconcile any test records so that customers and downstream staff do not mistake them for real work.

The acceptance record should state what passed, what remains dependent on the incumbent and which defects prevent a safe cutover. It should also name who accepts the residual limitations. A successful file import with failed customer matching is not a successful operating handover.

Use a cutover plan with a clear recovery point

Plan the transition around actual work cycles. Specify when new inputs switch, how in-flight cases are assigned and when both parties reconcile the completion ledger. Freeze only the changes that would undermine the transfer, and communicate the freeze to the people who normally update rules or mappings.

Set a recovery point before live actions begin. If the replacement cannot complete a required case or duplicates an action, staff need to know whether to stop new intake, restore the prior operator or use the manual queue. Recovery must account for actions already taken; restarting from the beginning can repeat an email, order creation or other external effect.

After a stable observation period appropriate to the workflow, revoke unused access, retire obsolete schedules and confirm the status of retained data. Keep evidence of those actions. Do not describe a transition as finished while the former integration can still issue instructions or while unresolved customer cases remain unassigned.

Avoid a universal “30-day exit” promise. The right timetable depends on volume, system access, contract terms, the availability of business owners and how much implementation must change. What matters is an explicit plan whose dependencies and acceptance criteria have been tested.

Decide how much portability is worth buying

Not every small workflow needs a second production system waiting in reserve. A low-volume internal report may be adequately protected by documented rules, a recoverable export and a manual procedure. A time-sensitive order operation may justify stronger recovery arrangements and regular exercises.

Likewise, portability should not become a reason to build every tool from scratch. A proprietary feature can create real value. The commercial decision is whether that value outweighs the documented switching effort and continuity exposure, given the business's actual needs.

Ask prospective providers to explain who owns configuration, mappings, evidence and open exceptions; what can be exported; what must be rebuilt; and how the receiving operator will demonstrate readiness. Have the appropriate commercial or legal advisers resolve contractual rights rather than inferring them from a technical demo.

If you are comparing delivery models, start with our guide to building, buying or commissioning a managed AI workflow. Then define the pilot acceptance criteria that the original and replacement arrangements should both satisfy.

Sources

[1] NIST AI RMF Playbook: Manage. Primary framework guidance on managing AI risks, third-party dependencies, contingencies and decommissioning. The framework is voluntary.

[2] Microsoft: Export and import a non-solution cloud flow. Primary documentation describing flow packages and their distinction from solution packages.

[3] Microsoft: Export a solution-aware cloud flow. Primary documentation for solution exports and associated components; platform behavior should be checked for the configuration being transferred.

[4] GitHub: Reviewing and revoking authorization of GitHub Apps. Primary documentation distinguishing user authorization and app installation access.

Work out the economics · Use a practical playbook