checklist
AI tool migration checklist for small teams
A practical checklist for migrating from one AI tool to another, covering scope, access, connectors, data cleanup, cutover, rollback, employee notice, and post-migration verification.
Use this checklist after the team decides to replace, consolidate, downgrade, or move workflows from one AI tool to another.
AI tool migrations fail when teams only move users and forget the rest: prompts, files, shared projects, meeting bots, OAuth grants, browser extensions, APIs, webhooks, transcript storage, admin settings, renewal dates, and old-tool data cleanup. This checklist keeps migration practical: define scope, verify the new tool, move a limited workflow, cut over, remove old access, clean connectors, communicate the change, and verify after seven days. If the new tool changes the data, workflow, or connector scope, run the AI Tool Risk Checker before the wider rollout.
Bottom line
Do not migrate an AI tool as a simple license swap. A safe migration needs:
- A written scope.
- A limited pilot.
- Approved users and data classes.
- Connector and source-system review.
- New-tool admin control evidence.
- Old-tool access and data cleanup.
- Employee notice.
- Rollback and post-migration verification.
Use the Small Team AI Security Checklist as the baseline control set for the new tool.
When to use this checklist
| Situation | Use this checklist? | Why |
|---|---|---|
| Replacing one approved AI tool with another | Yes | Covers migration, cleanup, and evidence. |
| Consolidating duplicate AI tools | Yes | Ensures old tools are actually removed. |
| Moving from pilot to approved tool | Yes | Converts pilot evidence into operating controls. |
| Downgrading or changing plans | Yes | Checks whether controls, retention, and admin features change. |
| Moving only a small workflow | Yes | Keeps data and connector boundaries explicit. |
| Ending a tool without replacement | No | Use the AI tool decommissioning checklist instead. |
| Deciding whether to replace a tool | Not yet | Use the AI tool replacement decision matrix first. |
If a migration starts because a finding could not be fixed, link the migration record to the AI tool remediation plan template.
Migration readiness matrix
| Readiness area | Ready | Not ready |
|---|---|---|
| Decision | Replacement, downgrade, or consolidation decision is recorded. | Team only has a preference or demo feedback. |
| Owner | Business, admin, data, source-system, and finance owners are named. | One person is expected to handle everything informally. |
| Scope | Workflows, users, data classes, and connectors are listed. | ”Everyone moves” or “same as before” is assumed. |
| Controls | New-tool admin settings and data controls are verified. | Vendor claims are accepted without admin evidence. |
| Pilot | Limited pilot has success and stop criteria. | Tool is rolled out directly to all users. |
| Cleanup | Old-tool access, data, connectors, billing, and renewal cleanup are assigned. | Old tool is left active “just in case.” |
| Rollback | Rollback owner and criteria are written. | Team has no plan if cutover fails. |
Do not begin broad migration until every “not ready” item has an owner and due date.
Pre-migration inventory
| Inventory item | What to capture | Owner |
|---|---|---|
| Users and groups | Current users, admins, guests, bots, service accounts, and groups. | Admin owner |
| Workflows | Approved workflows, actual workflows, and workflows to block. | Business owner |
| Data classes | Customer data, internal data, source code, transcripts, files, regulated data, and public content. | Data owner |
| Connectors | OAuth apps, browser extensions, meeting bots, APIs, webhooks, CRM sync, calendar sync, repository access, and automations. | Source-system owner |
| Shared assets | Shared projects, prompts, templates, files, saved instructions, exports, and workflow notes. | Tool owner |
| Admin settings | SSO, logs, retention, training, sharing, export, deletion, and workspace controls. | Admin owner |
| Billing | Renewal date, plan, cancellation path, downgrade path, and support ownership. | Finance owner |
| Evidence | Prior scorecard, renewal decision, replacement matrix, remediation item, and evidence packet. | Reviewer |
Use the AI tool audit evidence packet template if evidence is scattered.
New tool control checklist
Before moving users, verify:
- The new tool has a named owner and backup owner.
- SSO or identity controls are configured where available.
- Admin roles are limited to approved admins.
- Default sharing settings match the approved workflow.
- Retention, export, deletion, and training settings are documented.
- Connector scope is approved by each source-system owner.
- Browser extension permissions are reviewed if the tool ships an extension.
- Meeting bot behavior is reviewed if the tool records or summarizes meetings.
- Logs or review evidence are available for future audits.
- The new tool has a review date and renewal owner.
If the new tool cannot meet the baseline, return to the replacement decision matrix before moving forward.
Connector migration map
| Connector type | Migration question | Evidence needed |
|---|---|---|
| OAuth app | What scopes are granted in the new tool, and who approved them? | OAuth app record and scope note. |
| Browser extension | Which domains, tabs, files, or page content can the extension access? | Extension review and allowlist record. |
| Meeting bot | Which meetings can it join, where are transcripts stored, and who can share them? | Bot policy and retention record. |
| CRM or support desk | Which customer records can sync, and who reviews generated summaries? | Source-system approval and workflow note. |
| Code repository | Which repositories, branches, issues, pull requests, or terminals are in scope? | Repository approval and coding policy note. |
| File storage | Which folders or documents can be read or written? | Folder scope and owner approval. |
| Calendar or email | Which calendars, inboxes, or messages are in scope? | Source-system approval and user notice. |
| Webhook or automation | What action can the automation trigger? | Automation owner and rollback plan. |
Do not copy connector access from the old tool without a fresh source-system owner review.
Data migration checklist
| Data type | Move? | Required control |
|---|---|---|
| User accounts | Yes, if approved | Create only approved users and groups. |
| Shared prompts and templates | Maybe | Review for customer data, source code, credentials, or sensitive internal data before moving. |
| Uploaded files | Usually no | Move only approved files with owner sign-off. |
| Customer records | Rarely | Use approved workflow and data owner review. |
| Meeting transcripts | Rarely | Follow retention, consent, deletion, and storage rules. |
| Saved chats or project history | Usually no | Export only if required and reviewed. |
| Admin logs or evidence | Yes | Store in evidence packet, not inside the new tool if unnecessary. |
| Billing records | No | Keep in finance system or controlled records. |
Prefer a clean start unless there is a real business reason to migrate historical content.
Cutover plan
| Time | Action | Owner | Evidence |
|---|---|---|---|
| T-7 days | Confirm scope, owners, pilot result, and rollback criteria. | Business owner | Migration record. |
| T-5 days | Configure new tool controls and connector scope. | Admin and source-system owners | Settings and connector evidence. |
| T-3 days | Send employee notice and approved workflow rules. | Tool owner | Notice text. |
| T-1 day | Freeze old-tool changes except approved business-critical work. | Business owner | Freeze note. |
| Cutover day | Add approved users to new tool and remove old-tool default access. | Admin owner | User export. |
| Cutover day | Move only approved prompts, templates, and workflow notes. | Tool owner | Migration checklist. |
| Cutover day | Remove or narrow old connectors. | Source-system owner | Connector cleanup evidence. |
| T+1 day | Check user access, data boundaries, and connector behavior. | Admin owner | Verification record. |
| T+7 days | Review incidents, friction, exceptions, and old-tool cleanup. | Business owner | 7-day review record. |
Keep the cutover small if the tool touches customer data, source code, transcripts, production systems, or finance workflows.
Rollback plan
| Rollback trigger | Action | Owner |
|---|---|---|
| New tool exposes broader data than approved | Pause affected workflow and remove connector. | Source-system owner |
| Required admin control is unavailable | Stop rollout and return to restricted old-tool workflow. | Admin owner |
| Pilot users cannot complete core workflow | Extend pilot or restore old workflow temporarily. | Business owner |
| Customer, candidate, or regulated data is mishandled | Pause workflow and start incident review. | Security or privacy reviewer |
| Migration creates duplicate records or data loss | Stop cutover and use backup workflow. | Tool owner |
| Billing or renewal timing creates lock-in risk | Pause plan change and escalate to finance owner. | Finance owner |
Rollback should be written before cutover, not invented after something breaks.
Employee notice template
Copy and adapt this notice.
Subject: AI tool migration for [team/workflow]
We are moving [workflow] from [old tool] to [new tool] on [date].
Approved use:
- [workflow 1]
- [workflow 2]
Do not use the new tool for:
- [blocked data or workflow]
- [blocked connector or source system]
What changes:
- Use [new tool link or access path] after [date].
- Stop using [old tool] for [workflow] after [date].
- Keep customer data, source code, transcripts, and internal files within the approved rules.
Questions or issues:
- Business owner: [name]
- Admin owner: [name]
- Data or privacy owner: [name]
If the new tool behaves unexpectedly, stop using it for the affected workflow and report it in [channel].Do not include private customer data, account IDs, credentials, or billing details in the notice.
Old tool cleanup checklist
After cutover, confirm:
- Old tool users, guests, admins, bots, and service accounts are removed or restricted.
- Old OAuth apps, browser extensions, webhooks, APIs, meeting bots, and automations are removed or narrowed.
- Old shared projects, files, prompts, templates, and saved instructions are exported or deleted according to the rule.
- Old transcripts and summaries follow the approved retention and deletion plan.
- Old billing, renewal, cancellation, and support ownership are updated.
- Old tool is marked decommissioned, restricted, or exception in the inventory.
- Old tool evidence is stored in the evidence packet.
- Any remaining access has a named owner, expiry date, and review date.
If cleanup is incomplete, create a remediation item rather than leaving the old tool active without a decision.
7-day verification
| Check | Pass condition |
|---|---|
| User access | Only approved users, groups, admins, guests, bots, and service accounts remain. |
| Connector scope | New and old connectors match approved source-system decisions. |
| Data use | Users are not moving blocked data classes into the new tool. |
| Workflow fit | Users can complete the approved workflow without shadow tools. |
| Old-tool cleanup | Old access, connectors, billing, and retention actions are complete or tracked. |
| Incidents | No unresolved migration incident, near miss, or user-reported data issue remains. |
| Exceptions | Any exception has an owner, expiry, and compensating controls. |
| Evidence | Migration record, cleanup record, and review date are stored. |
Link the 7-day verification record from the next quarterly review scorecard.
Migration record
Copy this into your review record.
AI tool migration record
Old tool:
New tool:
Migration decision:
Migration date:
Business owner:
Admin owner:
Data owner:
Source-system owner:
Finance owner:
Migration owner:
Approved workflows:
Blocked workflows:
Approved data classes:
Blocked data classes:
Approved users and groups:
Approved connectors:
Rollback triggers:
Old-tool cleanup actions:
7-day verification date:
Evidence packet:
Next review date:Store links to evidence, not raw customer records, private transcripts, source code, credentials, or billing records.
Metrics to track
| Metric | Why it matters |
|---|---|
| Migrations completed | Shows operational progress. |
| Migrations with rollback | Shows quality of replacement decisions. |
| Old-tool access removed on time | Shows cleanup discipline. |
| Old connectors removed on time | Shows source-system risk reduction. |
| Migration incidents or near misses | Shows whether cutovers create new risk. |
| Exceptions created during migration | Shows where controls were not ready. |
| User friction after cutover | Shows whether the new tool is usable. |
| Duplicate subscription cost after cutover | Shows whether finance cleanup happened. |
If old-tool cleanup misses the deadline, treat it as a remediation item or exception.
Evidence checked
- NIST: AI Risk Management Framework
- NIST: Cybersecurity Framework 2.0
- NIST: Privacy Framework
- NIST CSRC: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- Cybergiz: AI Tool Risk Checker
- Cybergiz: Small Team AI Security Checklist
- Cybergiz: AI tool replacement decision matrix
- Cybergiz: AI tool remediation plan template
FAQ
Is this different from a replacement decision?
Yes. The replacement decision says whether to keep, replace, restrict, downgrade, or decommission a tool. The migration checklist is the execution plan after the decision is made.
Should we migrate old chats and files?
Usually no. Migrate historical content only when there is a clear business need, data owner approval, and a retention rule. A clean start reduces unnecessary data exposure.
Who should own connector cleanup?
The source-system owner should approve or remove connectors. The AI tool admin can execute the change, but the owner of Gmail, Drive, Slack, GitHub, CRM, calendar, or file storage should approve the scope.
How long should both tools run in parallel?
Keep overlap short and explicit. A small pilot may need 1-2 weeks. Broad parallel use should have a deadline, owner, and cleanup plan so the old tool does not become shadow infrastructure.
What if users keep using the old tool?
Remove or restrict access, update the employee notice, and confirm the new tool supports the required workflow. If users need the old tool for a valid reason, record it as an exception with expiry.
How does this connect to the main checklist?
The Small Team AI Security Checklist defines the baseline controls. This migration checklist verifies that the new tool and the old-tool cleanup both meet that baseline.