Your files don't care which Claude account you use. Your skills, settings and memory do. When we moved from a personal Claude account to the Team plan on 2 and 3 November, our folders came across untouched, and almost everything that lived in the account had to be moved by hand.
This is part 1: the account, the skills, and what we learned moving them. Projects, connectors and code sessions come in part 2.
What we were moving
My business partner and I work across several businesses from one shared folder. Every Claude session reads a start-here file in that folder first. One Claude project orients the week and keeps our team tasks, each business has its own project connected only to its own folder, and each code repo has its own Claude Code session.
My personal admin stays in a separate, private workspace. The Team account holds work only.
Check before you touch anything
The first session of the move didn't move anything. It read the start-here file, the team task list and each project's current state, then checked our folders against the map. Two projects still described a "current phase" that was months old. Nobody had noticed, because nothing had forced a full read. A move does.
Fix stale notes before you carry them into a new account.
Skills belong to the account, not the computer
Nothing moved by itself. Skills live in your Claude account, and there was no button to download them, so we packaged each one as a ZIP file from the synced copies on my machine: one folder per skill, named exactly as the skill.
Two skills on my list turned out not to be ours. They were Anthropic's own example skills, already in the Team account. Check what's yours before you plan to move it.
Skills also need code execution switched on. On a personal plan that's in Settings, Capabilities ("Code execution and file creation", or "Create and edit files" in the newer layout). On a Team plan, an owner turns on code execution and Skills in the organisation's policy settings.
The two rule skills went in first, because the start-here file points at them. The core writing-voice skill went in before the two brand-voice skills that call it.
Nine of our ten skills moved. The slide-deck skill stayed behind on purpose. It came from a public GitHub repo, we rarely used it, it overlaps with the built-in deck tools, and its broad trigger could take over ordinary deck requests. If we need it again, we'll install a fresh copy. A move is a good time to ask whether you still need each skill, not only how to move it.
The test that passed without the skill being there
This is the mistake I'd most like you to skip.
After uploading the first skill, I opened a fresh chat and asked it something only that skill knows. Perfect answer. Then it mentioned where it had found it: in the ZIP file sitting in the connected folder. The skill wasn't switched on. The upload had never happened.
The fix is to test each skill in a new chat with no folder connected and outside any project, so the only place the answer can come from is the installed skill. I uploaded the skills again by hand and the retest passed.
Here's the check we ran on every skill. Pick a rule only that skill contains, like a dated rule or a specific example. Ask a clean chat what the skill says, and compare the answer with the ZIP. "Uploaded" isn't proof. A skill save once failed on us without any warning.
Renames cascade
Our brand changed name earlier this year, from Nile AI to Nile Automate, but the brand-voice skill still carried the old name. Renaming it touched three skills and about ten files:
- The skill's own name and wording.
- Its source paths, which still pointed at our old folder.
- The core voice skill and the other brand skill, which both named it and had to be re-uploaded.
- About ten working files that referenced the old name.
Skills point at each other, and at your files, by name. Search for every reference before you rename.
Testing caught a half-done swap. The renamed skill loaded and passed. The same test also asked which skill the core voice skill hands brand content to, and the answer was still the old name. The updated core skill hadn't replaced the old copy in the account. When skills point at each other, test the pointer, not only the skill you renamed.
Updating a skill isn't the same as re-uploading it
We changed our transcript-cleanup skill so it files cleaned transcripts into a shared library by topic. The clean-chat check still saw the old version. It said there was no topic logic and wouldn't invent any.
What we do now when we update a skill:
- Delete the old skill, then upload the new one. Anthropic's help page gives delete and re-upload as the way to update a skill you uploaded yourself.
- Open the skill in settings and check the new section is there.
- Test in a chat started after the change. A chat that was already open kept answering from the old version. A brand-new one passed.
- Ask about the new behaviour. It's the only question that tells you which version is live.
Check the organisation's settings, not only yours
Web search was off for the whole new organisation. We got no warning. Research skills come back thinner. Skill sharing and code execution were already on. After a move, test each capability your skills depend on once: web search, code execution and sharing.
We left the unified Chat and Cowork setting on, and it didn't change how we split work between Cowork and Claude Code. Anthropic's admin guide for the unified experience is written for Enterprise, so check what applies to your plan. It lists three things worth knowing:
- Account memory moves to a new system, and the old memory may be deleted 14 days later. Put anything important in your files.
- Almost all files Claude gives you in a conversation are deleted with that conversation. Save the ones you want somewhere else.
- Scheduled tasks keep running after the chat that created them is deleted.
Write the rule down before you build
Sharing the folder with my business partner was parked at first, on purpose. Our house rules said no sync, and never put the workspace inside OneDrive, because a two-way sync once quietly undid a week of our work.
When I decided on a OneDrive copy after all, we rewrote the rule first: a one-way mirror from my Mac to the cloud, view-only for him, nobody edits the copy, deleted files kept for 30 days. The script came after the rule.
Writing the rule first was right. The mirror itself wasn't the answer. A one-way copy is a backup, not a workspace, so soon after this we moved the team's files to a Google shared drive the business owns, with an independent backup behind it. That move, and the mistakes in it, are in our next Field Note: "How to prevent long-term data loss: a backup and disaster recovery strategy for a small team".
The same thinking gave machine-level jobs their own home. Cowork can't run scheduled jobs or copy scripts on my Mac, so we set up a separate Claude Code session in its own folder for that kind of work. It can read everything, writes only in its own folder, needs my approval for every script, and is blocked from editing project code and the shared folder. Each project's code stays with that project's own code session.
Instructions tell a session what it should do. Permissions stop it doing the rest.
A checklist for your move
- List what lives in the account (skills, connectors, scheduled tasks, projects, memory) separately from what lives in your files.
- Read your start-here notes and fix anything stale before you move it.
- Decide whether you still need each skill. Leave behind what you don't use.
- Check which skills are yours. Anthropic's example skills are already there.
- Turn on code execution and skills, and check the organisation's settings, web search included.
- Upload in order: rule skills first, then the core skills other skills call.
- Test each skill in a new chat, outside any project, with no folder connected, using a rule only that skill contains.
- Before renaming a skill, search every skill and file for its name. Afterwards, test the skills that point to it.
- To update a skill: delete the old one, upload the new one, open it to check, then test in a new chat.
- Move anything important out of memory and into your files, and save the files Claude made for you.
- Write down any rule change before you build the tool that depends on it.
It took us two days, and most of that was checking. If you're planning the same move and want a second pair of eyes on your list, book a free intro call. Part 2, on projects, connectors and code sessions, is next.