Move your account to another provider

Your provider is the company storing your account data. Do you dislike their performance, jurisdiction, pricing or policy? Move to a different provider. You keep everything. Your DID, followers, posts, and Sifa ID profile records all come with you.

This is one of the things that sets the Atmosphere apart. It also takes a bit of care to do right.

What "moving" actually means

Three things happen during a provider migration:

1. The old provider exports your records as a CAR file. That file is a content-addressed archive of every record on your account.
2. The new provider imports those records and becomes the new home for everything.
3. The migration updates your DID document, so identity-resolution requests reach the new provider and not the old one.

Your DID does not change. A provider-issued subdomain needs a new home, because alice.bsky.social stops working after you leave Bluesky. Your own domain as your username survives the move without a change.

Before you start

• Know the provider that receives your account. Popular alternatives to Bluesky: Eurosky (EU-hosted, GDPR-aware), Tangled (EU, developer-focused), and Blacksky.
• Some providers need an invite code. Check the signup page of the target provider first, and get a code if it asks for one.
• Pick a moment when you can afford some downtime. The migration takes minutes. DNS propagation and a new sign-in to each app take longer.
• Back up first. The protocol supports safe migration, and mistakes still happen. Take a CAR-file export of your old provider before you start. In Sifa, Settings -> Account holds Export my data server via pdsls.dev. It opens pdsls.dev with your account loaded, and the export runs from there. From a terminal, goat repo export <your-username> does the same against com.atproto.sync.getRepo.

How to actually do it

You have got three options, ordered from easiest to most technical. Pick whichever fits.

Option 1: PDSmoover (browser-based, no install)

PDSmoover is a community-maintained browser tool by @baileytownsend.dev that walks through the entire migration in your browser. No CLI, no install. It is the easiest path for most users moving between any two providers.

The flow on the page:

1. Enter your old username and old password. PDSmoover notes that the old password also becomes your new password.
2. Enter the new PDS URL, which is the address of the target provider. Add a new email and your new username. Add an invite code if the target asks for one.
3. Tick the "I understand" risk acknowledgement.
4. Hit MOOve.

A few caveats:

• It is third-party software. The source sits on tangled.org. Read it before you hand it your credentials.
• The page asks for your real password (not an app password), so use it on a device and network you trust.
• Roll-back works the same way as the other options (see What can go wrong below).

Option 2: your target provider's own migration flow

Some providers ship their own browser-based migration tool, so you need no third-party software. Today:

• Eurosky has a portal at portal.eurosky.tech. It handles signup and migration in the browser. On the route to Eurosky, use that portal.

The flow resembles PDSmoover. You give the portal your old credentials and a new username, and the portal does the work. The advantage over a third-party tool is the trust: one organisation receives both your account and your credentials.

Other providers may add similar flows. Check the target provider's docs.

Option 3: goat CLI (for developers)

If you would rather drive the migration from a terminal, use goat, the official AT Protocol command-line tool maintained by Bluesky.

goat account migrate \
  --pds-host https://eurosky.social \
  --new-handle alice.eurosky.social \
  --new-password '<set-on-new-provider>'

It prompts you for your old-account password and asks you to confirm. goat then:

1. Creates the account on the new provider.
2. Exports every record from the old provider.
3. Imports the records into the new provider.
4. Requests a signed PLC operation to update your DID document.
5. Activates the new account and deactivates the old one.

The whole flow usually takes 1 to 5 minutes depending on how many records you have.

During the migration: what happens to apps

During the migration, the apps of your open sessions may show stale data for a few minutes. That covers Sifa, Bluesky and the rest. They cache identity-resolution responses for short periods. Once the cache expires they pick up the new provider automatically.

After the migration you may have to sign out of Sifa and sign in again for a fresh session. Your old provider issued the session token, so the token dies when that provider releases your account.

After the migration: checklist

Whichever tool you used, run through these to verify the move worked end-to-end:

• Resolve your username. curl -s "https://api.bsky.app/xrpc/com.atproto.identity.resolveHandle?handle=alice.eurosky.social" should return your DID.
• Inspect your new PDS. curl -s "https://eurosky.social/xrpc/com.atproto.repo.listRecords?repo=<your-did>&collection=id.sifa.profile.position" should return your Sifa positions.
• Sign into Sifa with the new username. Profile should render exactly as before.
• Check your Bluesky timeline. Posts, follows, and followers should be intact.
• Check your Atom feed. https://sifa.id/p/<new-username>/activity.atom should resolve and show the same entries as before.

If you used a custom domain as your username (alice.com), the domain still works. You do not need to update DNS unless you also changed your underlying username. The DID lookup follows the same TXT record or .well-known/atproto-did file you set up originally.

What can go wrong

"My username resolution fails."
DNS caches sometimes hold on to the old record. Wait 10 to 15 minutes and retry. If it still fails, the PLC update may be missing. Look up your DID on the PLC directory and confirm that the operation went through.

"Sifa shows my profile as empty after migration."
Your AppView session needs to refresh. Sign out and back in. If it persists for more than 30 minutes, open an issue.

"Some records did not transfer."
Rare, but possible if your old provider had a record the protocol considers invalid. Most migration tools print a list of skipped records at the end. Look at them on pdsls.dev under your old DID and re-create them by hand on the new provider.

"I want to roll back."
You can. While your old provider still holds the deactivated account, the protocol can re-activate it. Contact your old provider's support. The operation is reversible for a limited window.

Sifa-specific notes

• Sifa's AppView reads everything by DID. Since your DID does not change, your profile URL (https://sifa.id/p/<your-did> or the username-based equivalent) stays the same.
• Every endorsement that you received points at your DID. They all survive the migration.
• The Activity feed recomputes from the firehose. The migration can drop an event in flight, and every later event lands as usual.

Want to go deeper

• Your data on a provider: where your records actually live and how to inspect them.
• DIDs, usernames, and providers: the model that makes migration safe.
• What is the Atmosphere?: the bigger reason this works.