Skip to main content
Back to BlogAnalyse IA

Migrating Your Claude Accounts to SSO Without Losing Anything

September 20, 2026

Switching Claude to single sign-on is not moving accounts: it is creating new ones. Here is what carries over, what does not, and the sequence of steps that keeps you from getting locked out.

If you are looking for the why first (revocation, domain control, parallel accounts), start with Why Enable Single Sign-On for Claude. This article is for the person who has to carry out the migration.

One fact drives everything else: a Claude account address never changes. It is the account identifier, not an attribute you edit in a settings screen.

Everything follows from that. If your organization is switching from one domain to another, or if your people were using personal addresses and need to move to their corporate ones, you are not migrating their accounts: you are creating new ones. The old accounts keep existing alongside the new ones, with their history intact, and nothing merges them.

This is not a flaw to work around. It is the constraint to plan for.

So what actually carries over? Conversations do not, not between two different addresses. Anthropic does document an import feature, but it only links a personal account and an organization sharing the same address; nothing transfers a conversation history from one address to another. Projects, uploaded files, and preferences all need to be recreated. The primary owner role is unique and transfers manually. If that applies to you (and it does the moment a domain changes), tell your teams before the switch, not after: someone who loses six months of conversations without warning also loses confidence in the deployment.

Memory does transfer. You export it and then import it as a text file, under Settings › Memory › Start import. Anthropic flags the feature as experimental and notes that Claude prioritizes work-related content. Our field observation: a large memory history does not go through in one block, you need to break it into chunks, and no specific limit is documented, so it takes some trial and error.

⚠️ The Order of Steps Is What Protects You

This is the core of this article. The "Require SSO" setting closes the "Continue with email" door, which is the only fallback exit. If you enable it before confirming that SSO login actually works, you can find yourself locked out of your own organization with no second path in.

The sequence we follow:

  1. Know who holds the primary owner role. It is unique and transfers manually only. Establish this before you start, not during.
  2. Verify your domain with a DNS TXT record.
  3. Enable "Restrict organization creation" from the start (the pitfalls below explain why this cannot wait).
  4. Configure the identity provider and provisioning (JIT or SCIM).
  5. Actually log in through SSO, with a test account and with an admin account. Not "the configuration looks good": a successful login, on screen.
  6. Only then, enable "Require SSO".

Do not compress steps 5 and 6. That is the one that does not forgive mistakes.

The Five Pitfalls We Encountered

The first one presents itself as an offer. After the first SSO login, a screen prompts for Pro or Max; anyone who clicks ends up paying for a personal subscription they are already covered for through the organization's seat. The right move is to choose the free option and let the organization provide access. Write this out word for word in your communication to users: it is the easiest instruction to forget and the most visible one on a credit card statement.

The second comes from automatic provisioning, which does not pick up an existing account. JIT creates the user on their first login, but if an account already exists under the same address, it passes right by. Those people need to be invited manually, one by one. Build the list beforehand, or you will be discovering it in the middle of the rollout.

The third is silent, which is what makes it nasty. When no seat is available, the login still succeeds and the person is left without access; no message, anywhere, explains why. Count your seats before you start, and keep a buffer.

The fourth explains why "Restrict organization creation" appears at step three and not at the end. Anthropic documents a procedure to claim and migrate accounts on a domain, subject to conditions; our experience on a Team plan is blunter: a personal account already created under a verified domain does not get pulled in. The only moment you control that is before it exists.

The fifth is more about hygiene than technique. By default, only the primary owner can export the organization's data; a setting ("Allow members to export their own data") is left disabled. Enabling it means a manager does not have to personally handle employees' data for a simple export, and it saves you an awkward conversation.

Our Checklist Before Touching the First Setting

  • Who is the primary owner? (a specific name, not "the IT team")
  • How many accounts already exist under the domain, and which ones are changing addresses?
  • How many seats are available?
  • Is the message to users written out, including "choose the free option"?
  • Have we communicated what will not carry over: conversations, projects, files?
  • Have we tested an actual SSO login before requiring SSO?

Six questions. If even one is unanswered, nothing gets enabled.


A well-sequenced migration is invisible to users. A poorly sequenced one takes a week to untangle. If you are planning yours and want someone to review your sequence of steps, reach out.

Sources Cited

  • Anthropic, Set up single sign-on (SSO), support.claude.com/en/articles/13132885-set-up-single-sign-on-sso (updated September 17, 2026)
  • Anthropic, Important considerations before enabling single sign-on (SSO) and JIT/SCIM provisioning, support.claude.com/en/articles/10276682 (updated August 11, 2026)
  • Anthropic, Claim and migrate accounts on your domain, support.claude.com/en/articles/14625619 (updated September 3, 2026)
  • Anthropic, Set up JIT or SCIM provisioning, support.claude.com/en/articles/13133195 (updated September 17, 2026)
  • Anthropic, Import and export your memory from Claude, support.claude.com/en/articles/12123587 (updated September 16, 2026)
  • Anthropic, Export your organization's data, support.claude.com/en/articles/13346720 (updated August 20, 2026)
  • Anthropic, Export your Claude data, support.claude.com/en/articles/9450526 (updated September 19, 2026)

The pitfalls described and the recommended sequence of steps come from a migration carried out by our team. They are presented as our own experience, distinct from what the publisher has documented.