Claude Code handover documentation: what you should receive at the end of a project

At the end of a Claude Code project you should receive everything someone else would need to keep working on your site without the original vendor: the code in your own repository with its full history, instructions for building, testing and deploying, the Claude Code setup (CLAUDE.md files, shared settings, hooks, skills and a list of connections), the scripts used for bulk changes, a record of decisions and known issues, and a list of every account and credential with proof that the vendor's access has been removed.

Claude Code adds one twist to a normal software handover. Some of what makes a vendor's sessions work well can live on the vendor's own machine rather than in your repository. Anthropic's docs say auto memory, the notes Claude keeps for itself, is machine-local, and personal instruction and settings files stay out of git. A good handover moves anything your project depends on into the shared files before the vendor leaves.

This guide lists what a complete handover pack contains, explains the Claude Code-specific items, and gives you a short test to prove the handover works.

The handover pack at a glance

The rollout scope-of-work template has a shorter handover checklist; this guide goes deeper into each item.

The repository and how to run it

The repository should be in your organization's account from the start; if it isn't, transfer it before final payment. Check that the main branch contains the finished work and that any open branches are either merged or listed with a reason.

The README or runbook should let a competent newcomer do five things without help: install what's needed, build the site with one documented command, run the checks, deploy through your normal process, and roll back a bad deploy. If a step needs a secret, the document should say where the secret is stored, never the secret itself.

The Claude Code setup

These files are what make Claude Code behave the same way for the next person who opens your project.

• Project CLAUDE.md. Anthropic's memory documentation says the project file is shared with team members through source control and recommends keeping each file under 200 lines. It should hold build and test commands, conventions and a "never change" list. Our guide to writing a CLAUDE.md for a website covers what belongs there.
• Shared settings. Anthropic's settings documentation says to commit .claude/settings.json "so everyone who clones the repository gets the same permissions, hooks, and plugins." Check that it includes deny rules for secret files.
• Hooks, skills and subagents. Any automatic checks, reusable instructions (SKILL.md files) and specialized subagents, each with a one-line note on what it does. Our guide to skills explains what these files are.
• Plugins and MCP connections. A list of each one, where it came from, what access it has and who owns the account behind it.

What won't come across unless you ask

Three kinds of Claude Code files are personal and don't travel with the repository:

• Auto memory. Notes Claude writes for itself are stored on the vendor's machine; the docs say auto memory is machine-local and files are not shared across machines or cloud environments.
• CLAUDE.local.md. Personal project instructions, meant to stay out of git.
• .claude/settings.local.json. Personal settings, including standing approvals someone gave at a permission prompt ("Yes, and don't ask again"). When Claude Code creates this file, it keeps it out of commits.

None of these should hold anything your project depends on. Ask the vendor to review them and move any project rules, warnings or commands into the shared CLAUDE.md or settings before handover. Then run /context in a session on a fresh clone to confirm which memory files load.

Scripts, redirects and the source of truth

Claude Code work can produce small scripts: a crawler, a migration step, a bulk find-and-replace. When we rebuilt eseospace.com, the repository held 262 small build and fix scripts and one redirects file with 235 rules by the end of September 2026. Without notes, a collection like that is hard for anyone else to use safely. Ask for each script to have a line saying what it does, whether it is one-off or reusable, and whether it is safe to run twice.

The redirects file deserves its own check: every rule tested, and a note on how to add new ones. Our guide to building and testing a redirect map shows how.

Most important is a map of where things are edited. On our own site, a publishing step once regenerated every post from source files and deleted edits that had been made only in the built copy. A one-page source-of-truth map (content edited here, settings edited there, these folders are generated and must never be edited by hand) prevents that for whoever comes next.

Decisions, known issues and QA evidence

Ask for a short decision log: the major choices, the alternatives considered, and anything tried and abandoned. On our rebuild, a clean Next.js rewrite was abandoned on day one because it broke animations, accordions, widgets and menus, and a person decided to keep the theme's own JavaScript. A note like that saves the next team from trying the same thing.

QA evidence shows what was true at handover. For our rebuild, the SEO parity check compared titles, meta descriptions, robots, canonicals, structured-data types and H1s on old and new pages, and after one fix found zero differences across all 217 pages checked. Your vendor's evidence should match the acceptance criteria in your contract. The rebuild case study describes these checks in more detail.

Access, credentials and offboarding

1. List every account the vendor used, its role and its owner.
2. Remove or downgrade the vendor's access to the repository, hosting, CMS, analytics, Search Console and Claude seats, and record the date.
3. Rotate every credential that was shared, including API keys used on staging.
4. Disconnect any MCP connections or integrations that used the vendor's own accounts, or move them to yours.
5. Confirm in writing that the vendor holds no copies of secrets and has deleted local copies of your work it no longer needs. Claude Code stores session transcripts, which can include your code, in plain text on the machine that ran them, for 30 days by default.

If you followed our agency onboarding checklist, you already have the list of what was granted, which makes this step quick.

How to test the handover

Tie final sign-off, and final payment if your contract allows, to these tests passing. Our guide to Claude Code contract terms covers how to write that into the agreement.

Conclusion

A good Claude Code handover leaves you able to carry on without the vendor: the repository and its history in your account, runbooks, the full Claude Code setup in committed files, documented scripts and redirects, a source-of-truth map, decisions and known issues, and a clean access record. Test it with a fresh clone and a newcomer's change before you sign off. If you want a build or migration delivered with this kind of handover, see our Claude Code development service. More guides are in our Claude Code Guide.

Frequently asked questions