AI tool offboarding checklist for small businesses

An AI tool offboarding checklist helps a small business stop using a system without losing important work, leaving live integrations behind or assuming that cancelling a subscription deletes everything.

Retirement can look simple from the billing page. In practice, an AI tool may hold prompts, uploaded files, generated content, conversation history, logs, custom assistants, knowledge bases and personal information. It may also have access to email, cloud storage, a CRM, publishing tools or automation platforms. People and other workflows may depend on its outputs without appearing on the account owner’s list.

Offboarding is therefore a business change, a data-handling task and an access-control task. Use this checklist when a trial ends, a supplier is replaced, a model or feature is withdrawn, a workflow is no longer useful, or the risk is no longer acceptable.

The aim is not to keep every artefact forever. It is to decide deliberately what must be transferred, retained or deleted; keep essential work running; remove every route back into company systems; and record enough evidence to show what happened.

Start with a retirement decision, not a cancellation

Before anybody closes the account, write a short retirement record:

System and scope: product, plan, workspace, AI features and workflows being retired.
Reason: trial ended, replacement selected, supplier change, cost, performance, security, compliance or no remaining business need.
Owner: person coordinating the work and person accepting any residual risk.
Dates: last day of normal use, export deadline, access-removal date and contract end.
Dependencies: people, customers, integrations and downstream processes affected.
Information: business records, personal data, prompts, files, logs and outputs held by or connected to the system.
Destination: approved replacement, manual process, archive or deletion route.
Evidence: exports, deletion confirmation, revoked connections and final approval.

Update the status in your AI tool register to retiring. Do not mark it retired until the checks are complete.

The UK Government’s 2026 AI Risk Management Toolkit treats risk management as a lifecycle activity from identifying a use case through to retirement. It also recommends policies and processes for transparency around decommissioning. For a small team, the retirement record is a proportionate way to make the decision visible and assign the work.

1. Map what will stop, break or disappear

Ask the owner and actual users what the tool does today. Do not rely only on the purpose written down when it was approved; trials expand, features change and people find new uses.

Map:

recurring tasks, scheduled agents and background automations;
browser extensions, plug-ins, API clients and webhooks;
folders, mailboxes, calendars, analytics accounts and business systems it can reach;
forms, webpages or apps that send information into it;
reports, drafts, recommendations or records consumed elsewhere;
custom instructions, prompts, knowledge sources and evaluation sets;
shared links, public assistants and externally accessible outputs;
named users, guest users, service identities and administrators;
billing owner, contract owner and supplier contacts.

Look in the connected systems as well as the AI product. An integration may have been authorised from a Google, Microsoft, CRM or automation account and remain active even after the AI workspace is abandoned.

For every dependency, choose a disposition: move, replace, pause, archive or stop. Name the person responsible and the date. If nobody can explain what would happen when a scheduled workflow stops, pause it in a controlled window and observe the result before deleting its configuration.

2. Protect continuity before removing the old route

Decide which business functions must continue and how they will operate after retirement. A replacement tool is only one option; a manual route may be safer while a new workflow is tested.

For each important task, confirm:

the new owner and method;
the information and permissions required;
the acceptable interruption window;
how queued or partly completed work will be handled;
which customers, staff or suppliers need to be told;
what will happen if the replacement fails;
when the old system can safely stop.

Do not copy an old AI workflow into a new product and call that a migration. Reassess the job, data, permissions, approval points and supplier terms. Test the replacement against representative work before depending on it. The AI agent testing checklist provides a practical acceptance process.

Avoid running two live systems indefinitely “just in case”. Parallel running should have a purpose, an owner and an end date. Otherwise the old tool continues to receive information, retain access and incur cost while becoming less visible.

3. Inventory the material inside the tool

List what the business may need after the account closes:

source files and uploaded documents;
final approved outputs and business records;
prompts, system instructions and reusable templates;
custom assistants, agents, actions and workflow definitions;
knowledge-base content and retrieval settings;
test cases, expected results and performance evidence;
audit logs, approval history and incident records;
account, usage, invoice and contract records;
supplier notices, support cases and decision records.

Classify each item as transfer, retain, delete or do not export. Exporting everything can create a second unmanaged data store, while exporting nothing can remove evidence or operational knowledge the business genuinely needs.

Keep final business records in the system that normally owns them. A customer decision belongs in the approved customer record, not only in an AI chat. An approved campaign belongs in the content or campaign system, not only in a generated-output history.

The National Cyber Security Centre’s secure AI development guidance identifies models, data, prompts, software, documentation, logs and assessments as AI-related assets that should be tracked and protected. Its machine-learning end-of-life guidance also highlights appropriate retention of logs and the need to decommission models and associated data deliberately.

4. Export selectively and verify the result

Before the export window closes, check what the supplier can actually provide. A “download my data” function may produce conversation text but omit configuration, permissions, knowledge sources, audit events or machine-readable workflow definitions.

For each required export:

identify the authoritative source and owner;
choose an approved destination with suitable access controls;
minimise personal and confidential information where possible;
record the export date and format;
open a sample and confirm it is complete and usable;
check whether relationships, timestamps and approvals survived;
protect or securely transfer any secrets separately;
set a retention or review date for the exported copy.

Do not place API keys, passwords or access tokens inside an export folder or migration note. Create new credentials for a replacement system instead of copying long-lived secrets from the old one.

Test restoration, not just download. If the business depends on a set of approved templates, open them in the destination and confirm that the right people can find and use them. A compressed archive that nobody can interpret is not a continuity plan.

5. Decide what happens to personal information

Identify the personal information held in prompts, uploads, generated outputs, logs, feedback, user profiles and connected systems. Then decide what must be returned, retained, anonymised or erased, with whoever owns data protection for the business.

The Information Commissioner’s Office’s storage limitation guidance says personal information should not be kept longer than needed and should be erased or anonymised when there is no justification to retain it. It also distinguishes deletion from merely taking information offline and explains that backup copies need to be considered.

Where the supplier acts as a processor, inspect the contract rather than assuming what happens at cancellation. The ICO’s controller–processor contract guidance explains that end-of-contract terms must address return or deletion of personal information and deletion of copies unless the law requires storage. It recognises that backups may follow a later deletion cycle if the information is put beyond use and appropriately protected in the meantime.

Record:

the data categories and people affected;
why each retained category is still needed;
where the retained copy will live and who can access it;
the retention or review date;
the supplier’s deletion process and timescale;
how backups, logs, safety records and legal holds are treated;
whether data was used to train or improve a shared service and what the applicable terms say;
the evidence received when deletion or return is complete.

Do not promise that all information has been erased if you have only clicked a delete button. State what you have verified, what the supplier says will happen later and any lawful retention that remains.

6. Revoke people, agents, integrations and secrets

Removing user accounts inside the AI tool is only one layer. Work through every identity and connection that could still reach data or act on the business.

Revoke or rotate as appropriate:

employee, contractor, guest and administrator accounts;
service accounts and agent identities;
single sign-on assignments and group memberships;
OAuth grants and connected-app permissions;
API keys, personal access tokens and webhook secrets;
integration credentials held in automation platforms;
browser extensions, desktop apps and mobile sessions;
shared links, published assistants and public endpoints;
access from the tool into email, storage, CRM, analytics and publishing systems;
access from other systems into the retired tool.

The NCSC’s guidance for using SaaS securely recommends joiner, mover and leaver processes, periodic access review and revocation of unnecessary access. It also notes that SaaS products can include machine automations and third-party integrations, which need the same attention as human users.

Use the AI agent permissions checklist as a reverse checklist: every identity, tool, data source and action approved at launch should have a corresponding removal or transfer decision at retirement.

Rotate a credential if you cannot prove that the retired system never received or stored it. Disable the connection at the authoritative system, not only in the AI interface. Finally, try the old route and confirm that access now fails as intended.

7. Stop automation safely and inspect unfinished work

List every scheduled run, queue, draft, webhook and retry. Then stop new work entering the system before removing the ability to inspect what is already there.

Check for:

messages prepared but not approved or sent;
records created but not synchronised;
queued jobs and automatic retries;
webhooks that will keep delivering data;
temporary files and caches;
scheduled reports that another person expects;
alerts or monitors that point only to the retiring system;
fallback workflows that could reactivate the old connection.

Capture the state of important in-flight work and decide whether to complete, cancel or recreate it. Tell affected users what will no longer happen automatically. Silence is risky: a team may assume a follow-up, report or customer update is still running long after the workflow has stopped.

Where the retirement follows an incident, preserve relevant evidence before deleting or altering it. Coordinate the sequence with the AI incident response plan, and do not let routine offboarding destroy information needed for investigation, contractual duties or specialist advice.

8. Close the commercial and supplier relationship

Confirm more than the subscription status. Review:

notice periods, renewal dates and final charges;
licences assigned through a reseller or app marketplace;
minimum terms, usage commitments and credits;
support or professional-service access;
data return and deletion obligations;
confidentiality and intellectual-property terms that continue after termination;
supplier access to your environment;
open incidents, complaints, disputes and support cases;
any equipment, domains or accounts controlled by the supplier.

Ask for written confirmation of the effective termination date and the status of company data. Record any deletion cycle or retained category the supplier identifies. If the answer conflicts with the contract or your requirements, escalate it before the workspace becomes inaccessible.

The AI supplier due-diligence checklist includes exit questions that are easier to resolve before purchase. Feed any difficult offboarding experience back into the next procurement: export format, deletion evidence, notice period and integration visibility should influence the next supplier decision.

9. Verify retirement from both sides

Treat retirement as a testable change. A second person should review higher-risk systems or any workflow that handled sensitive information, communicated externally or could take consequential action.

Verify that:

essential records are in the approved destination and readable;
the replacement or manual process works for representative tasks;
scheduled jobs and inbound data flows have stopped;
users, agents, tokens, integrations and public links no longer work;
required logs and decision records are retained securely;
unnecessary exported and local copies have been removed;
supplier deletion or return steps are recorded with their timescales;
final invoices and renewals are resolved;
staff know the approved route and cannot accidentally restart the old one;
the tool register, process documentation and system diagrams show the new state.

Check identity-provider logs, connected-app pages, automation platforms and the receiving business systems. Evidence from the retired product alone cannot show that every external token or data flow has been removed.

If something cannot be completed, record the residual item, owner, protective measure and due date. For example, a supplier backup may remain beyond your direct control until its documented deletion cycle; the record should say that instead of marking the whole task “done”.

10. Close with a short retirement report

The final record can fit on one page:

Decision: system, scope, reason, owner and dates.
Continuity: replacement or manual route tested.
Records: items transferred or retained, destinations and review dates.
Data: categories deleted, returned, anonymised or still awaiting a supplier cycle.
Access: users, integrations, public links and credentials removed or rotated.
Automation: jobs stopped and in-flight work resolved.
Commercial: contract, billing and supplier access closed.
Verification: checks performed, evidence location and reviewer.
Residual items: owner, control and completion date.
Learning: changes required in policy, procurement, testing or documentation.

Change the AI tool register status to retired, add the retirement date and link to this record. Keep the record under the business’s normal retention policy; do not keep the retired system running merely to preserve evidence that should have been exported properly.

Frequently asked questions

Is cancelling the subscription enough?

No. Cancellation may stop billing or future use, but it may not remove connected-app permissions, API credentials, public links, local exports, user accounts or supplier-held information. Complete and verify each layer separately.

Should we export every conversation before closing the account?

Usually not. Export what the business must preserve for continuity, accountability or another defined purpose. Bulk exports can duplicate personal and confidential information into a less controlled location. Apply an explicit retention decision and review date.

Can we delete the account immediately after a security concern?

Contain the risk quickly, but coordinate deletion with incident response. Revoke dangerous access and stop automation first; preserve the logs, configuration and other evidence needed to establish what happened. Obtain specialist advice where contractual, legal, regulatory or insurance duties may apply.

What if the supplier cannot delete backups immediately?

Record the contractual position, deletion cycle, safeguards and date by which deletion is expected. Confirm that the information is put beyond normal use and protected in the meantime. Escalate where the arrangement does not meet the business’s requirements or applicable obligations.

What if an AI feature is embedded inside a product we still need?

Treat the feature as the offboarding scope. Disable it if the product allows, remove its connections and permissions, change staff instructions, handle its stored information, and monitor for re-enablement after product updates. If the feature cannot be separated, decide whether the whole product remains acceptable.

How do we stop staff returning to the old tool?

Provide a workable replacement or manual route, explain when the old route ends, remove sign-in and connected-app access, and update approved-tool guidance. If people were solving a real unmet need, blocking the product without addressing the job may simply create a new shadow tool.

Plan the exit when you approve the tool

The easiest offboarding starts before purchase. Record the owner, connected systems, export options, retention settings, contract exit terms, deletion process, credential locations and manual fallback while the system is still being assessed. Set review and retirement triggers in the AI tool register.

Then retirement becomes a controlled change instead of a forensic exercise. The business can preserve what matters, remove what no longer has a purpose and prove that an old tool no longer has quiet access to live work.

An AI marketing audit can identify forgotten tools, data flows and integrations before they become an exit problem. Ongoing AI marketing support can help small teams manage supplier changes and retire workflows without losing operational control.

Replacing an AI platform or closing down an old workflow? Talk to Drop Jaw Studio about ongoing AI support for a practical review of the dependencies, access and next operating route.

Sources checked on 12 October 2026: the UK Government AI Risk Management Toolkit, NCSC secure AI development, machine-learning end-of-life and SaaS guidance, and ICO storage-limitation and controller–processor contract guidance, linked above. This is practical operational guidance, not legal, cyber-security or data-protection advice.