--- title: Move your account to another provider description: Migrate your Atmosphere account from one provider to another without losing followers, posts, profile data, or Sifa records. Browser tools and CLI options. --- Your provider is the company storing your account data. Don't like them anymore (performance, jurisdiction, pricing, policy)? Move to a different provider and keep everything. Your DID, followers, posts, and Sifa 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. **Records are exported from the old provider** as a CAR file (a content-addressed archive of every record on your account). 2. **Records are imported into the new provider**, which becomes the new home for everything. 3. **Your DID document is updated** to point identity-resolution requests at the new provider instead of the old one. Your **DID doesn't change**. Your handle may need re-pointing if you used a provider-issued subdomain (`alice.bsky.social` doesn't work once you're not on Bluesky). If you set up [your own domain as your handle](/docs/use-your-own-domain), that part is unaffected. ## Before you start - Know **which provider you're moving to**. Popular alternatives to Bluesky: [Eurosky](https://eurosky.social) (EU-hosted, GDPR-aware), [Tangled](https://tangled.org) (EU, developer-focused), and [Blacksky](https://blacksky.community). - Some providers require an **invite code**. Check the target provider's signup page first and grab one if you need it. - Pick a moment when you can afford some downtime. The migration itself takes minutes, but DNS propagation and re-signing into apps can take longer. - Back up first. The protocol is built for safe migration, but mistakes happen. Keep a CAR-file export of your old provider before you start. ## How to actually do it You've got three options, ordered from easiest to most technical. Pick whichever fits. ### Option 1: [PDSmoover](https://pdsmoover.com) (browser-based, no install) [PDSmoover](https://pdsmoover.com/moover) is a community-maintained browser tool by [@baileytownsend.dev](https://bsky.app/profile/baileytownsend.dev) that walks through the entire migration in your browser. No CLI, no install. It's the easiest path for most users moving between any two providers. The flow on the page: 1. Enter your **old handle** and **old password**. PDSmoover notes that the old password also becomes your new password. 2. Enter the **new PDS URL** (the target provider's address), a **new email**, your **new handle**, and an **invite code** if the target needs one. 3. Tick the "I understand" risk acknowledgement. 4. Hit **MOOve**. A few caveats: - It's third-party software. Source is on [tangled.org](https://tangled.org/@baileytownsend.dev/pds-moover) if you want to read it before trusting it with 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](#what-can-go-wrong) below). ### Option 2: your target provider's own migration flow Some providers ship their own browser-based migration tool, no third-party software needed. Currently: - **[Eurosky](https://eurosky.social)** has a portal at [portal.eurosky.tech](https://portal.eurosky.tech) that handles signup + migration in-browser. If you're going to Eurosky, that's the one to use. The user experience is similar to PDSmoover: you give the portal your old credentials and a new handle, the portal does the work. The advantage over a third-party tool is that you're trusting the same organisation you're moving to. Other providers may add similar flows. Check the target provider's docs. ### Option 3: `goat` CLI (for developers) If you'd rather drive the migration from a terminal, use [`goat`](https://github.com/bluesky-social/indigo/tree/main/cmd/goat), the official [AT Protocol](https://atproto.com) command-line tool maintained by Bluesky. ```bash goat account migrate \ --pds-host https://eurosky.social \ --new-handle alice.eurosky.social \ --new-password '' ``` 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 While the migration is in progress, apps you're signed into (Sifa, Bluesky, others) **may show stale data for a few minutes**. They cache identity-resolution responses for short periods. Once the cache expires they pick up the new provider automatically. After migration you may have to **sign out and sign back in** to Sifa to refresh the app's session. The session token was issued by your old provider, so it stops working 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 handle.** `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=&collection=id.sifa.profile.position"` should return your Sifa positions. - **Sign into Sifa with the new handle.** Profile should render exactly as before. - **Check your [Bluesky](https://bsky.app) timeline.** Posts, follows, and followers should be intact. - **Check your Atom feed.** [`https://sifa.id/p//activity.atom`](https://sifa.id/p/alice.eurosky.social/activity.atom) should resolve and show the same entries as before. If you used a custom domain as your handle (`alice.com`), the domain still works. You don't need to update DNS unless you also changed your underlying handle. The DID lookup follows the same TXT record or `.well-known/atproto-did` file you set up originally. ## What can go wrong **"My handle 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 not have applied. Look up your DID on the [PLC directory](https://web.plc.directory) to confirm 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](https://github.com/singi-labs/sifa-workspace/issues). **"Some records didn't 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](https://pdsls.dev) under your old DID and re-create them by hand on the new provider. **"I want to roll back."** You can. As long as your old provider hasn't deleted the deactivated account, you can re-activate it via the protocol. 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 doesn't change, your profile URL (`https://sifa.id/p/` or the handle-based equivalent) stays the same. - Endorsements you've received reference your DID. They survive the migration intact. - The [Activity feed](/docs/activity-feed) recomputes from the firehose. Any in-flight events during migration may be missed, but new ones land normally. ## Want to go deeper - [Your data on a provider](/docs/your-data-on-a-provider): where your records actually live and how to inspect them. - [DIDs, handles, and providers](/docs/dids-handles-providers): the model that makes migration safe. - [What is the Atmosphere?](/docs/what-is-the-atmosphere): the bigger reason this works.