Checklist · 5 minute read
AI Handover Checklist: Transferring a System That Works
Handover fails when documents transfer and knowledge does not. Beyond architecture and runbooks, the receiving team needs ownership of the evaluation suite, the cost model, the incident history, and a period of shadowing where they operate the system while the original team is still available.
Handing over an AI system fails when the documents transfer and the knowledge does not. This checklist covers making it land, drawn from FISTA Solutions' forward deployed engineering delivery practice.
What has to transfer?
Six things, only two of which are documents.
| Item | How it transfers |
|---|---|
| Architecture and code | Documentation plus walkthrough |
| Evaluation suite | Ownership, plus they run it |
| Runbooks | Documents, then rehearsal |
| Cost model | Dashboard access and explanation |
| Incident history | Conversation, not a wiki page |
| Operational judgement | Shadowing only |
Documentation
Necessary groundwork; do not mistake it for the handover.
- Architecture documented with an end-to-end request walkthrough
- Design decisions recorded with their reasoning
- Prompt conventions and why specific instructions exist
- Data flows and retention documented
- Dependencies listed including provider versions
- Known fragilities and workarounds written down
- Things tried and abandoned, with reasons
Evaluation transfer
The most important item. See how to build an agent evaluation harness.
- Evaluation suite ownership formally transferred
- Receiving team has run it end to end themselves
- Case provenance explained: where each came from
- Scoring criteria explained and their author identified
- Process for adding cases demonstrated
- Known gaps in coverage stated honestly
- Domain experts who set the criteria introduced
Operations
Rehearse rather than read.
- Runbooks reviewed and updated before transfer
- Receiving team has performed a rollback themselves
- Alert routing changed to the receiving team
- On-call rotation transferred with a handover period
- Deployment performed by the receiving team at least once
- Access to all systems verified, not assumed
- Escalation path to the original team during overlap agreed
Cost and commercial
The receiving team inherits the bill and the decisions behind it.
- Cost dashboards transferred with access verified
- Cost per task explained per operation
- Routing decisions and their rationale explained
- Budget position and forecast handed over
- Vendor contracts and renewal dates transferred
- Provider account ownership moved
- Efficiency work already identified passed on
History and context
The part that only transfers through conversation.
- Incident history walked through with people who were there
- Why unusual code exists, explained case by case
- Stakeholders and their expectations introduced
- Open issues and their status reviewed
- Planned work and its rationale handed over
- Users and reviewers introduced to the new team
- Relationships with content owners transferred
Verification
Prove the transfer by having them operate it.
- Receiving team ships a real change through the full process
- They run the evaluation and interpret the results unaided
- They handle an incident or a rehearsed one
- They answer questions about the system without help
- Gaps found during verification are closed
- Overlap period covers at least one release cycle
- Formal acceptance only after the above, not before
What are the most common failures?
Treating documentation as the handover. Transferring code without the evaluation suite. A cutover date with no overlap. Incident history left as a wiki page. And acceptance signed before the receiving team has operated anything.
Who should own this?
Both leads own it jointly until verification is complete. Handover owned only by the departing team gets rushed; owned only by the receiving team lacks the knowledge to ask the right questions.
How often should it run?
Per handover, with a scheduled overlap rather than a date. Re-verify a month after the original team has gone, since gaps surface once the safety net is removed.
What evidence should it produce?
The completed checklist, records of the receiving team's first change and first incident handled, and a post-handover review a month later.
What if the original team is already gone?
Reconstruct from what exists and accept it will be incomplete. Start with the evaluation suite if there is one; if there is not, building it is the first task, because without it nothing can safely change.
Read the incident history and the change log, and treat unexplained code as fragile until proven otherwise. Budget significantly more time than a proper handover would have taken. See forward deployed engineer knowledge transfer.
What should you do first?
Have the receiving team run the evaluation suite unaided. Whatever they cannot interpret is what the handover has not covered.
How FISTA Solutions helps
FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: handover verified by the receiving team operating the system through a real change and a real incident, with an overlap period rather than a cutover date, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.
To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI onboarding checklist for engineers.
Share-ready article cover
Download the generated social format.
Clear answers
Questions raised by this field note.
Straightforward guidance for evaluating scope, fit, and the next step.
01What is most often lost in handover?
The reasoning. Documents say what the system does; what disappears is why it was built that way, what was tried and abandoned, and which parts are fragile.
02Why is evaluation ownership critical?
Because without it the receiving team cannot safely change anything. They inherit a system they must not touch, which is the worst possible position.
03How do you verify a handover landed?
By having the receiving team operate the system — ship a change, handle an incident, run the evaluation — while the original team watches rather than helps.
04How long should the overlap be?
Long enough to cover a release cycle and ideally an incident. A cutover date with no overlap transfers responsibility without transferring capability.
05What about vendor handovers?
The same, with more emphasis on export and access. Confirm the receiving team can run everything without the vendor before the contract ends, not after.
Continue exploring
Related capabilities
Start with the hard problem
Need the outcome owned, not merely analyzed?
Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.