When you move your Mastodon account from one instance to another, your followers do not automatically follow the new account. The transfer relies on a specific ActivityPub message called a Move activity. Many users expect the migration to be instant, but the process involves a handshake between servers that can take hours or even days to complete. This article explains exactly how the Move activity propagates through the fediverse, including the technical steps, timing, and common points of failure.
Key Takeaways: How the Mastodon Move Activity Travels Between Servers
- Preferences > Account > Move from a different account: Initiates the Move activity on the old server, which generates an ActivityPub message.
- Old server sends Move to each follower’s server: The old instance queues and delivers the Move activity to every server that hosts one of your followers.
- Follower’s server processes the Move: The receiving server validates the aliases, updates the follow relationship, and may queue the new account for fetching.
How the ActivityPub Move Activity Works in Mastodon
The ActivityPub protocol defines a Move activity as a way to indicate that an actor (your account) has relocated to a new actor (your new account). Mastodon implements this through a two-step alias verification process. Before the Move activity is sent, you must first set an alias on your old account pointing to the new account, and a separate alias on the new account pointing back to the old account. This bidirectional alias ensures that only the legitimate owner of both accounts can initiate the migration.
Once the aliases are set, the old Mastodon instance generates a JSON-LD document conforming to the ActivityPub specification. The document includes the type field set to Move, the object referencing the old account, and the target referencing the new account. The old server signs this document with its private key and sends it to every server that has one of your followers.
The Delivery Queue
Mastodon does not send the Move activity to all servers simultaneously. Instead, the old instance places the message into a delivery queue. The queue processes messages one by one, respecting rate limits and retry policies. If a follower’s server is temporarily unreachable, Mastodon retries the delivery up to five times with exponential backoff. The initial retry interval is 30 seconds, doubling after each failed attempt. After five failures, the server discards the message and logs the error. This queuing mechanism is the primary reason migrations can take hours to complete for accounts with many followers.
Server-Side Validation
When a follower’s server receives the Move activity, it performs several validation checks. First, it verifies the HTTP signature to confirm the message came from the old account’s server. Second, it checks that the old account’s alsoKnownAs property contains the new account’s URI. Third, it checks that the new account’s alsoKnownAs property contains the old account’s URI. If all three checks pass, the server updates the follow relationship: it unfollows the old account and follows the new account. If any check fails, the server ignores the Move activity and logs a warning.
Steps the Move Activity Follows From Start to Finish
The propagation of the Move activity involves a sequence of actions on both the old and new servers. Follow these steps to understand the full path the message takes.
- Set the alias on the old account
In your old Mastodon account, go to Preferences > Account > Move from a different account. Enter the handle of your new account (e.g.,@username@newserver.social). This sets thealsoKnownAsproperty on your old account. - Set the alias on the new account
Log into your new Mastodon account. Go to Preferences > Account > Move to a different account. Enter the handle of your old account. This sets thealsoKnownAsproperty on your new account and completes the bidirectional alias. - Initiate the Move from the old account
Return to your old account. Click the Move followers button. The old server generates the Move activity and adds it to the delivery queue. - Old server delivers the Move to each follower’s inbox
The old server iterates through your follower list. For each unique server, it sends an HTTP POST request containing the signed Move activity to that server’s inbox endpoint. - Follower’s server validates and processes
The receiving server checks the signatures and aliases. If valid, it updates the follow relationship. The server also fetches the new account’s public profile and avatar to cache locally. - New server receives follow requests
As each follower’s server processes the Move, it sends a standard Follow activity to the new account. The new account’s server adds the follower to the new account’s followers list.
Common Points of Failure in Move Activity Propagation
Even with correct alias setup, the Move activity can fail to propagate to all followers. Understanding these failure points helps you diagnose problems quickly.
Follower’s Server Rejects the Move Due to Missing Alias
The most common failure is a missing or incorrect alias. If you forget to set the alias on the new account, the receiving server cannot verify the bidirectional relationship. The server discards the Move activity, and the follower remains subscribed to the old account. To fix this, verify both accounts have the alsoKnownAs property set by inspecting the JSON representation of each account (append .json to the profile URL).
Old Server Cannot Reach a Follower’s Server
If a follower’s server is down, rate-limited, or blocking the old server’s IP, the delivery fails. Mastodon retries five times, but if the server remains unreachable, the Move is not delivered. The follower must manually unfollow the old account and follow the new account. You can check the old server’s logs for delivery errors. Server administrators can adjust the retry limit in the Mastodon configuration file.
Followers Lost After Account Migration Between Instances
If followers appear to have been lost, check that the new account is not set to private. A private account requires manual approval for each follow request. The Move activity sends a standard Follow activity, which gets queued as a pending request. The new account owner must approve each follower manually. Set the new account to public during the migration window to automate this process.
ActivityPub Move vs Manual Re-Follow: Propagation Differences
| Item | ActivityPub Move | Manual Re-Follow |
|---|---|---|
| Initiation | Old server sends a single Move activity | Each follower must search and follow the new account |
| Propagation speed | Minutes to hours depending on queue size | Immediate for each follower who acts |
| Follower effort | Zero — automatic transfer | High — each follower must manually act |
| Reliability | Depends on server uptime and alias correctness | Depends on follower awareness |
| Server load | High — old server sends N messages | Low — each follower sends one Follow activity |
The ActivityPub Move activity automates follower migration but introduces server-side dependencies. Manual re-follow gives followers control but requires effort. For accounts with more than 100 followers, the Move activity is the only practical method.
You can now trace exactly how the Move activity travels from your old server to each follower’s server. After initiating the migration, check the old server’s logs for delivery confirmations. For maximum success, keep both accounts active for 48 hours after the move. A practical next step is to verify the alsoKnownAs property on both accounts using the Mastodon API before clicking the Move button.