AI Risk Report #3: Budgeting for an AI Platform Change

Treat the exit path as part of implementation

A vendor may change an API, pricing model, feature, or product direction. Whether the change is manageable depends on how much of your business process is tied to that platform and how well the dependencies are documented.

Before adoption, identify which information the platform holds, which systems connect to it, and what work stops if it becomes unavailable. Ask how you would export the data and continue the essential process manually.

This is a planning exercise, not a prediction that every vendor will fail.

Inventory more than the data

A usable export is important, but moving a file does not recreate a working process. Your workflow may depend on permissions, scheduled jobs, prompts, document formats, webhooks, dashboards, and human review steps.

Record the business rule separately from the vendor configuration. For example, document who approves a proposal and which fields are required, rather than relying entirely on a visual workflow to explain the process.

Keep representative test cases with known acceptable outcomes. They make it easier to compare a replacement without relying on a persuasive demonstration.

Build the migration budget from the work

Include discovery, data cleanup, account setup, integration changes, testing, training, parallel operation, and decommissioning. Track the internal time required as well as the outside project cost.

Running two systems briefly may be sensible, but decide which is authoritative during that period. Without that rule, people can update different records and create reconciliation work.

Do not assume that every integration must be rebuilt or that all existing knowledge becomes useless. Some interfaces and business rules can transfer cleanly. Scope the actual difference before committing to a budget.

Test the cutover and the way back

Define the acceptance criteria before migration. Check permissions, source records, calculation results, review queues, notification behavior, and failure handling with representative data.

Plan the cutover window and the last point at which you can safely return to the old system. A rollback may require reconciling records created after the switch. Document who makes that decision and how users will be informed.

Retain the necessary records and access while you verify the new process. Do not cancel the old service simply because the new interface looks ready.

Make ownership visible

The handoff should identify the account owner, operational owner, support terms, renewal dates, and data-export procedure. Keep configuration and documentation where the organization can access them without depending on one individual.

Review the plan when a major integration or business requirement changes. A tested, understandable exit path is more useful than an arbitrary migration reserve or a promise that one platform will never need replacing.