How to Plan a Mastodon Mass Migration for a Whole Community

Moving an entire community from one Mastodon server to another is a complex task. Individual account migration is straightforward, but a coordinated group move requires careful planning to avoid losing followers, posts, or community trust. The process involves server administrators, moderators, and regular members working together. This article explains the complete workflow for a community mass migration, including pre-move checks, the server move tool, and post-migration verification steps.

Why a Community Migration Requires More Than Individual Moves

A single Mastodon account migration moves your followers and follows to a new account. The old account becomes a redirect. For a whole community, the scale introduces additional challenges. Every member must complete the move individually. If even one person skips the migration, the community becomes fragmented. Followers who do not migrate lose access to the private timeline of the group. Server administrators must coordinate a cutover date, export the instance database, and communicate deadlines clearly. Without a plan, members may end up on different instances with no way to find each other.

The core feature that makes this possible is the Mastodon account migration tool. It transfers followers, follows, lists, and muted or blocked accounts. Public posts remain on the old server. Private posts and direct messages do not migrate. For a community, the server admin can also export the entire local database, which includes all public posts, for archival or re-import on the new server. This step is optional but recommended for communities that want to preserve their full history.

Steps to Plan and Execute a Community Mass Migration

The process splits into four phases: preparation, individual migration, server-side tasks, and verification. Each phase must happen in order. Skipping preparation causes confusion and lost connections.

Phase 1: Preparation and Communication

1. Choose the new server
   Select a Mastodon instance that accepts the entire community. Check its terms of service, moderation policies, and server location. Ensure it supports the same language and content rules as the old server.
2. Set a migration deadline
   Announce the cutover date at least two weeks in advance. Post the date on the server’s local timeline, in a pinned post, and on any community channels outside Mastodon such as a Discord server or mailing list.
3. Create a migration guide
   Write step-by-step instructions for non-technical members. Include screenshots of the Preferences > Account > Move from a different account page. Explain that they must first create a new account on the new server before starting the move.
4. Ask each member to export their data
   Instruct members to go to Preferences > Import and Export > Export. Download the CSV files for follows, lists, blocks, and mutes. These files can be imported into the new account after the move.

Phase 2: Individual Account Migration

1. Create a new account on the target server
   Each member registers a new account on the chosen instance. The new account must have a different username than the old one if the old server is still running. If the old server will shut down, the new account can reuse the same username.
2. Start the move from the old account
   On the old account, go to Preferences > Account > Move from a different account. Enter the new account’s handle in the format @username@newserver.social. Click the Move Followers button. This sends a request to the new server to redirect followers.
3. Confirm the move on the new account
   On the new account, go to Preferences > Account > Move from a different account. Enter the old account’s handle. Click the Move Followers button. This authorizes the transfer. The old account will now display a redirect banner pointing to the new account.
4. Import CSV data into the new account
   Go to Preferences > Import and Export > Import. Upload the CSV files for follows, lists, blocks, and mutes. The import may take a few minutes. The imported follows will not trigger notifications to those users.

Phase 3: Server Administrator Tasks

1. Back up the old server’s database
   The server admin runs the Mastodon backup command: docker exec mastodon-db-1 pg_dump -U postgres mastodon_production > mastodon_backup.sql. This exports all public posts, user accounts, and media metadata.
2. Download media files
   Use rsync or a similar tool to copy the public/system directory from the old server. This directory contains uploaded images and videos. The admin can later serve these files from a static archive or re-upload them to the new server.
3. Set up redirect on the old domain
   After the migration deadline, configure the old server’s web server to redirect all requests to the new server. Use an HTTP 301 redirect for the entire domain. This ensures that old profile links still work.

Phase 4: Verification and Cleanup

1. Check follower counts on the new account
   Each member should compare their follower count on the new account with the old one. A small discrepancy is normal because some followers may have left Mastodon or deleted their accounts. A large loss indicates a migration error.
2. Test that the old account redirects
   Open the old profile URL in a private browser window. Confirm that it shows the redirect banner with a link to the new account. If using a server-level redirect, verify that the URL automatically forwards.
3. Post a final announcement on the old server
   Pin a post on the old server’s local timeline with the new server address. Ask members to unfollow the old account and follow the new one. This catches anyone who missed the migration.

Common Mistakes and How to Avoid Them

Members forget to export their CSV files before the old server shuts down

If the old server is taken offline permanently, members lose access to their follows, lists, and blocks. The migration tool only transfers followers and follows. Lists, blocks, and mutes must be exported manually. Instruct members to export their data immediately after the announcement. Store the CSV files locally on their own computer.

Follower migration fails because the old account is deleted too soon

The old account must remain active until all followers have been redirected. Deleting the old account before the migration completes causes followers to lose the redirect link. Keep the old account active for at least 30 days after the migration deadline. The Mastodon documentation recommends keeping the old account indefinitely if possible.

Community members end up on different instances

Without a single target server, the community scatters. Some members may choose a different instance because of personal preferences. To prevent this, the community leaders should select one server and require everyone to move there. If some members refuse, create a shared list on the new server that includes all migrated members. Publish the list so others can follow it.

Private posts and direct messages are lost

Mastodon’s migration tool does not transfer private posts or direct messages. These remain on the old server. If the old server shuts down, they are lost forever. Advise members to manually copy any important private conversations before the migration. The server admin can export the database, but importing private posts into the new server requires technical expertise and may violate privacy expectations.

Item	Individual Account Migration	Community Mass Migration
Scope	One user moves followers and follows	All members move together to a new server
Preparation needed	None beyond creating a new account	Announcement, guide, deadline, CSV exports
Server admin involvement	None	Database backup, media download, domain redirect
Risk of fragmentation	Low — only the individual is affected	High — members may scatter to different instances
Post migration verification	Check follower count on new account	Check all members, test redirect, post final announcement

After the migration, the community can continue on the new server with minimal disruption. The old server can be archived or shut down according to the admin’s plan. Members should update any external links that point to their old profile, such as website bios or social media profiles. For administrators, the key takeaway is to communicate early and often. A well-announced migration retains nearly all followers. A rushed migration can lose half the community.