AI vendor lock-in / ownership / continuity

If You Leave Your AI Vendor,
Can Your Business Keep Working?

The files may be yours. The workflow may still depend on someone else. A practical guide to what a business should be able to keep, transfer, rebuild, and operate.

Build your handoff register ↓Examine what you control

BY DR. ROBERT URBANSCIENTIST · MARINE VETERAN · EXECUTIVE CONSULTANTPAPER BOAT MEDIA

The cancellation email is the easy part.

The company has decided to change its AI provider. Perhaps the price changed. Perhaps the service no longer fits. Perhaps the person who built the workflow has moved on and nobody can get a straight answer about how it works. Somebody asks for an export, and a folder arrives.

The folder contains thousands of records. It may even contain every record the agreement promised. Yet the business still cannot answer a more useful question: who can receive tomorrow’s work, understand what has already happened, and finish the job?

That is where I would begin an AI vendor exit conversation. I want to know which customer promises, employee routines, and business decisions depend on the relationship. Then I want to establish what the organization can actually carry forward. Owning information, being able to retrieve it, and being able to operate with it are three different conditions.

I am Dr. Robert Urban, founder of Paper Boat Media. My consulting work connects technology with the people, processes, and commercial decisions around it. When a business becomes dependent on a useful system, I want leadership to understand that dependence while the relationship is still working well. An orderly exit should be an available business decision, with known work and costs behind it.

This guide follows a fictional property-management company replacing an AI-assisted maintenance intake service. The service organizes messages, proposes categories, prepares summaries, and routes requests for staff review. The example is illustrative, with no invented client results. Its value is in the ordinary complications: open requests, attachments, permission differences, staff knowledge, and customers who should not have to explain the same problem again.

A useful dependency can still deserve an exit plan.

I would be cautious about a proposal that treats every proprietary feature as a mistake. A well-integrated service may save a team substantial work. Rebuilding every component to make it theoretically interchangeable can create cost and operating responsibility the business never wanted.

The question is whether the value justifies the dependence, and whether the organization understands what changing direction would require. A provider-specific capability may be a sensible choice when its benefits are clear, its boundaries are understood, and the exit cost is acceptable. Trouble begins when the dependence becomes visible only after the company needs to leave.

The UK government’s guidance on managing technical lock-in in the cloud makes this tradeoff explicit: integrated services can deliver useful benefits, while switching costs and portability deserve deliberate review. It also discusses testing components elsewhere to improve estimates of what a move would involve. That is cloud guidance for a public-sector audience; the useful business principle here is to examine value and reversibility together.

For the property-management company, the current service may have genuinely improved intake. Employees may like it. None of that answers whether the company can preserve open requests, move the source information, or operate a replacement without the incumbent’s staff. The exit conversation should be specific enough to respect what the service does well while revealing what the company has yet to establish.

Start with the work that cannot disappear.

Before making a list of technical assets, trace one ordinary request. A resident reports a leak. An attachment arrives. The service proposes a category, summarizes the message, and routes it to a coordinator. The coordinator corrects the property reference and adds a note. A contractor is assigned through the company’s approved process. The request remains open while the team waits for an update.

If the organization changes systems at that moment, which parts of that history must remain connected? A message without its attachment may be incomplete. An attachment without its property reference may be difficult to interpret. A completed-looking summary may hide an unresolved question. The next employee needs the current state of the work, not merely a copy of its earliest input.

Map the points at which the AI-assisted service reads, transforms, stores, or passes information. Identify the system that is authoritative for each record. If the final work order lives elsewhere, confirm how the intake record connects to it. If the current service is the only place an employee’s correction is stored, that correction belongs in the exit discussion.

The business owner of the process should name the minimum service that must continue during a transition. For this company, that might mean receiving requests, preserving the original message, making new work visible to an assigned coordinator, and maintaining the approved escalation process. Automated summarization may be temporarily dispensable. Losing a request is not.

This is narrower than a complete technology strategy. My CTO and technology leadership article addresses broader operating responsibility. Here, the immediate task is to find the work that an export or cutover could accidentally strand.

What can you keep, and what can you actually use?

I would ask the team to inventory the parts of the service in terms an owner and an operator can discuss together. Some assets may be controlled by the client. Others may be licensed, shared, provider-managed, or unavailable outside the service. Those distinctions need to be established from the actual arrangement, not inferred from who paid the invoices.

Access is a separate question. A company can have an agreed right to receive material while nobody on its staff knows how to obtain it. Conversely, an administrator may be able to download a file without the business having established the permitted uses of every item inside it. The appropriate commercial, legal, technical, and information owners should resolve their parts of the arrangement.

Part of the working system	What to establish	Evidence worth asking for
Business accounts and administration	Who controls the tenant, billing, recovery route, and authorized administrators	A verified account inventory and access test by the designated client owner
Original records and attachments	What is included, which relationships survive, and where authoritative copies live	A sample export reconciled to selected live records
Business instructions and configuration	Which rules, routing settings, templates, and prompts are client-specific and available	Readable configuration with versions and an explanation of where it is applied
Integrations and scheduled work	Which connectors, credentials, queues, and triggers keep the process moving	A dependency register with responsible owners and a transition sequence
Evaluation material	Which representative cases and expected outcomes can be retained and reused	A usable test collection with permissions and grading notes
Operating history	Which decisions, corrections, approvals, and logs are available	A history sufficient to explain selected open and completed cases
Provider-specific capability	What cannot simply be exported or transferred	A candid list of features to replace, rebuild, or retire
Human knowledge	What staff and suppliers know that has never been documented	A handoff exercise performed by somebody who did not build the service

The goal is a realistic inventory. Label an unresolved item as unresolved. A column full of confident “yes” answers is not useful if nobody has tried opening the files, tracing a record, or operating with the permissions described.

An export is evidence of a transfer, not yet of a working handoff.

For our property-management company, a spreadsheet of messages would be only a beginning. The team needs to know whether the export preserves request identifiers, timestamps, property relationships, attachments, status, assignment, corrections, and links to the system of record. Not every service will store those elements. The point is to identify where they exist and how they will be retained or reconstructed.

Ask for the format and its meaning. A field called “status” needs a definition. A date needs a timezone and an explanation of whether it records creation, receipt, or modification. A blank field may mean unknown, not applicable, omitted, or unavailable. A replacement team should not have to infer those distinctions by comparing a few lucky examples.

Inspect the receiving end as well. Can the replacement import the information while preserving the relationships that matter? Are attachments readable and matched to the correct request? Are permissions preserved or deliberately rebuilt? Does a record retain enough context for a coordinator to act without consulting the old interface?

Reconcile counts, identifiers, and selected content. A matching total is useful but does not prove that every important field arrived intact. Sample difficult records: multiple attachments, several corrections, reassigned requests, merged duplicates, long histories, and incomplete cases. Preserve exceptions and investigate them before calling the transfer complete.

Timing matters. An export taken on Monday is already incomplete if new work and corrections continue through Thursday. The transition plan needs to explain how changes after the first export are captured, reconciled, and assigned. Otherwise, two individually reasonable copies can create a gap in the working record.

The practical test is whether a designated employee can complete a permitted task using the transferred information in the receiving environment. If that employee still needs the incumbent to explain each field or retrieve a missing attachment, the handoff has revealed work to finish.

The AI behavior may need to be rebuilt.

A workflow can have a portable description without having portable behavior. The new application may interpret the same instruction differently, retrieve different supporting material, or produce a summary that emphasizes different details. Keeping the text of a prompt is useful. It does not establish that the replacement will behave the same way.

For the maintenance intake service, the business might retain its approved category definitions and escalation rules. The old service’s internal classification behavior may not be available as a transferable component. The replacement therefore needs to be evaluated against the business’s intended outcomes, including how it handles ambiguity and when it asks a person to decide.

A hosted search collection can create another distinction. The company may be able to obtain its source documents while the vendor’s indexing, search configuration, or representations of those documents need to be rebuilt. Preserve the source material and its meaning, but have the technical team establish what can be reused in the receiving system. A folder labelled “knowledge base” does not explain the whole retrieval arrangement.

Ask what the proposed replacement can demonstrate. Use representative requests, the original source information, and the company’s expected handling. Compare the complete task: what the system produces, what the employee must inspect or correct, and what the next person receives. A superficially similar summary may omit the detail a coordinator needs to route the work properly.

My enterprise AI architecture article explains the mechanisms in greater depth. During an exit, the business decision is which behavior must be preserved, which behavior can change, and what evidence is needed before employees rely on the replacement.

Keep a record of the judgment your employees contributed.

An organization can spend months improving a system without recognizing where the improvements live. A coordinator corrects an ambiguous category. A supervisor changes the routing for a recurring request. An experienced employee spots a misleading summary and explains the missing context. Each correction may be valuable, but it may remain buried in a conversation or accessible only through the incumbent’s interface.

Ask which corrections became explicit business rules and which remained one-off decisions. A justified exception should not automatically become a general instruction. A general rule should not be trapped in an individual’s memory. The transition is an opportunity to make those distinctions readable.

For our fictional company, the team could review recurring correction patterns and document the approved handling with the responsible operational owner. Those notes would then inform training, evaluation, or configuration in the replacement. They should not be treated as proof that every employee correction was right; the company still needs to decide what it wants the new process to do.

This is one of the human parts of AI consulting that interests me most. The technology may organize the work, while the organization’s judgment accumulates through the people using it. A good handoff protects the useful knowledge those people contributed and gives the next operator enough context to apply it responsibly.

Separate a planned move from a sudden loss of service.

A cooperative transition with several weeks of overlap is different from losing access unexpectedly. They share some preparation, but they should not be represented as the same plan.

In a planned move, the incumbent may help produce exports, explain configuration, support reconciliation, and coordinate a cutover. The company can arrange training, test the receiving environment, and decide when to stop accepting new work through the old route. Timing and responsibilities can be negotiated within the actual commercial arrangement.

In a sudden interruption, that cooperation may be unavailable. The immediate priority may be preserving a minimum service with the information and access already under the company’s control. The fallback could be a simple approved intake process with human triage. It will have its own capacity limit, and leadership needs to know which work can wait and which requires immediate attention.

Do not call a document an emergency fallback merely because it contains another vendor’s name. The alternative must have the necessary access, information, people, and demonstrated capability for its intended role. It may be a reduced service rather than an identical replacement. That can be a sensible choice if the organization understands what changes.

The two plans should meet at a shared inventory of critical records, accountable owners, and minimum operating requirements. The planned exit explains how to move deliberately. The interruption plan explains what the company can do before a deliberate move is possible.

Choose one work item and rehearse the handoff.

A small exercise can expose questions that a large planning document misses. For the fictional property-management company, I would choose a permitted, representative request with a realistic history and ask a receiving coordinator to continue it in a controlled test environment. Use suitably prepared test material and the approved information-handling arrangements.

The exercise begins with the original message and its attachment. It includes the AI-generated summary, the employee’s correction, the current assignment, and the unresolved next action. The receiving coordinator should be able to explain what happened, identify what remains to be done, and take the next permitted step without guessing or contacting the person who designed the old workflow.

Watch where the exercise stops. Perhaps a status code has no definition. Perhaps the attachment is linked to an inaccessible account. Perhaps the replacement preserves the summary but drops the employee’s correction. Perhaps an assignment exists in both systems, and nobody knows which one owns the next action.

These are useful findings. Record the missing item, its consequence, the responsible owner, and the next test. Do not convert one successful request into a claim that the whole transition is ready. Extend the exercise to the case types and dependencies that matter, with the technical and operational team establishing the necessary scope.

The outcome should be something a sponsor can understand: what worked, what failed, what remains untested, and what must happen before a cutover decision. The company gains a more honest estimate of its exit effort even if it ultimately decides to stay with the current provider.

Open work needs an owner on both sides of the cutover.

A transition can move all the historical records and still mishandle the work arriving between systems. The plan should name the moment when new requests change destination, who observes that change, and how the team finds requests that went to the old route afterward.

For the property-management company, assign responsibility for open items, late attachments, replies to older messages, and corrections made during the overlap period. Decide which system is authoritative for each category of work. Running both systems without that decision can create duplicate assignments or leave each team assuming the other has taken responsibility.

Automated actions require particular care. A replacement should not repeat an action merely because it imported the record that triggered it previously. The technical team needs to establish how already-completed actions are recognized and how queued or partially completed work is reconciled. The business owner should understand the effect on staff and customers.

Define what would cause the team to pause the cutover and what a return to the prior arrangement would entail. A rollback promise is incomplete if records changed in both systems and nobody has planned how to reconcile them. Sometimes the safest response is to hold a narrow category of work for manual review while resolving the discrepancy.

The customer-facing question is simple: does the person asking for help still receive a coherent response? Internal completeness matters because it supports that experience. Residents should not have to become the integration layer by resending everything they already provided.

Give people a handoff they can operate.

A large technical folder may be necessary, but the employee taking over needs an operating view. Where does new work arrive? Which source should be trusted? What requires escalation? Who can fix access? What should the team do when the summary and original message disagree?

I would want a named receiving owner and an alternate, with time reserved for training and practice. The incumbent’s demonstration can help, but the receiving team should perform the work themselves. A handoff is stronger when someone who did not build the system can follow the instructions and explain the decisions they are making.

Separate ordinary operations from privileged administration. An employee should not need broad administrative access merely to complete a routine request. Equally, a designated administrator needs a recovery route that does not depend on a former employee’s personal account or an unavailable supplier contact. Establish those arrangements through the organization’s approved access process.

Keep the documentation close to actual tasks. Screenshots may become outdated; named responsibilities, source definitions, and escalation logic need ownership as the system changes. Document what the team must maintain, not only what the vendor delivered on the handover date.

Put the full transition cost beside the reason for leaving.

Changing providers can be the right decision even when it is expensive. Staying can also be sensible when the present service delivers value and the concerns can be addressed. Leadership needs a comparison that includes the work on both paths.

For a move, count preparation, exports, reconciliation, configuration, replacement development, evaluation, training, overlap periods, support, and internal staff time. Identify costs that remain unknown and who can establish them. A low replacement subscription does not describe the cost of making the replacement useful.

For staying, examine the ongoing terms, operating effort, limitations, and likely work required to address the original concern. Avoid treating accumulated setup cost as a reason to ignore a poor fit. Also avoid treating every proprietary feature as a reason to rebuild a service the team values.

The decision may be staged. The company could first regain control of account administration, obtain a usable export, document its rules, and rehearse a limited handoff. Those steps can improve its position without requiring an immediate replacement. If they reveal a larger dependency than expected, leadership can decide whether to invest in reducing it.

My role is to help connect those choices to the business. The relevant specialists still need to establish technical feasibility and review contractual or information-handling questions. A sound executive decision brings that work together rather than asking a single spreadsheet to settle every issue.

Close the old relationship with a record of what remains.

The final handoff should identify what the company received, what the receiving owner accepted, what remains unresolved, and which ongoing obligations or dependencies continue. A successful transfer does not mean every record should immediately be deleted everywhere. The organization’s authorized owners need to establish applicable retention, deletion, and preservation requirements with qualified advice where needed.

Coordinate the timing of access removal. Revoke unnecessary access through the approved process after the relevant work is complete and authorized owners have confirmed the sequence. Keep track of shared credentials, service accounts, connectors, scheduled jobs, and external collaborators so that the old relationship does not continue invisibly through a forgotten integration.

Ask for the available evidence of completed offboarding actions and record any exceptions. Some material may be retained under an applicable arrangement; some capabilities may remain in use through a separate service. The closure record should state the actual position rather than reducing a complicated transition to a checked box.

For the fictional property-management company, the meaningful conclusion is that its staff can receive and continue work, understand the record, and manage the new arrangement. That is the outcome the exit plan was designed to support.

The option to leave can improve the relationship you keep.

A provider who can explain the handoff clearly gives a client a better understanding of the service. The client can distinguish valuable expertise from avoidable dependence. Renewal becomes a conversation about the work and its value, with fewer unanswered questions underneath it.

That is consistent with the AI consulting firm I am building. I want clients to gain capability they can understand and put to use. When you work with me, the senior advisor in the conversation is the person doing the work. Clear ownership, useful documentation, and practical explanations belong in that relationship.

If you are considering an AI vendor change, bring the workflow that depends on it, the reason for the change, and what you already know about access and handoff. My AI consulting work can help clarify the business decision and the questions that need qualified answers. The first useful outcome is knowing what your company would actually have to do next.

Make the dependencies discussable

Your ownership and handoff register.

Record the current position for each part of the service, the person who can establish it, and the next piece of evidence you need.

This is a working record, not a readiness score. Selecting a status does not verify it. Keep the evidence and unresolved questions with the entry.

The worksheet does not submit or save your entries. Download the text to keep your notes. Use summaries rather than credentials, confidential records, or customer details.