A familiar username is not enough to establish that someone belonged to a community before it moved. Public profile names can be copied, inactive names can be claimed on the new service, and one person may have used different names on the two platforms. A reliable migration process needs three separate elements: a published eligibility rule, a fixed record date, and a secure way to demonstrate control of the old account. Membership recognition should be based on records held by the former platform rather than personal recollections or screenshots that anyone could reproduce.

The level of proof should also reflect what the member is trying to recover. Restoring an ordinary “legacy member” badge presents less risk than transferring moderator permissions, access to private discussions, prepaid membership time, or control of community resources. A single weak verification method should not unlock every type of status. The community should publish the migration rules before the old platform closes. Members then know which accounts qualify, which information will move, which rights require additional review, and how long they have to submit a claim.

A Fixed Record Date and an Official Claim Route

The migration notice should state the date on which the old membership database will be treated as final. An account created before that record date may qualify as an existing account, while one created afterward may need to join the new platform as a new member. The record date should not be confused with the claim deadline. The first determines whether an old account is eligible. The second determines how long the owner has to complete the migration process.

For example, a community might recognize accounts present in its database on September 30 while allowing claims until December 31. A member who applies in November may still qualify because the account existed on the record date. A person who created an account in October would not become an existing member merely by applying before the December deadline. The safest claim route begins inside the old account. A member who is already signed in can select a migration option and receive a one-time link, code, or token associated with that account’s internal ID. The new platform can then use the token to connect the new profile to the verified old record.

Mastodon’s official account-moving process illustrates the value of establishing a relationship between both accounts before a move. Its process requires the old and new accounts to be connected through account aliases before the migration is initiated. The system does not rely only on matching public names. A migration token should be single-use, time-limited, and attached to a specific old account. It should not be a general invitation code that can be forwarded to another person. Once redeemed, the token should no longer work.

Email invitations can provide a fallback when the old platform cannot support migration links. The invitation should be sent only to the address already recorded for the old account. A member should not be allowed to enter any address and claim that it was previously associated with the profile. Email access alone may be adequate for restoring an ordinary account. It is less persuasive when the claim involves administrative privileges or private data. Email accounts can be shared, compromised, abandoned, or reassigned by an employer or school.

Sensitive transfers should therefore trigger stronger authentication. OWASP recommends reauthentication after high-risk events, including account recovery, password resets, and suspicious account activity. A request to restore privileged access after moving to another platform belongs in the same risk category.

Evidence Levels for Old Account Ownership

The community should define several acceptable proof methods rather than improvising after disputes begin. The available method will depend on whether the old platform remains online and which records survived the migration. The strongest evidence is an authenticated action from the old account. The member might open a migration link while signed in, place a temporary code in a private profile field, or publish a specific verification phrase in a designated area. The code should be randomly generated and expire after a short period.

A public profile screenshot is much weaker. Usernames, avatars, post counts, and registration dates may already be visible to everyone. Another person can capture the same page and submit it as supposed proof. Confirmation through the registered email is useful when the old account is inaccessible but the email record remains available. The message should contain a one-time claim link rather than asking the member to send account information back through ordinary email.

Paid members may use a transaction reference, invoice number, payment date, or membership receipt when ordinary account matching fails. Support staff do not need full card details or an unredacted bank statement. Only the minimum information required to match the payment record should be collected. The same principle applies to identity documents. A community generally should not request a passport or national identification card simply to restore a forum badge. Official data-protection guidance defines data minimization as limiting collected personal information to what is adequate, relevant, and necessary for the stated purpose.

A proportionate verification structure might use a migration token or registered-email code for ordinary members, an old-account action plus payment evidence for paid access, and reauthentication with manual administrator review for moderators or administrators. Security questions based on memorable personal facts are poor substitutes for account control. Their answers may be guessed, found in old posts, shared with acquaintances, or forgotten by the legitimate member.

The review team should record which method was used without retaining unnecessary evidence indefinitely. A note such as “old-account token validated on November 4” is usually more appropriate than storing every screenshot and payment document submitted during the claim.

Separate Mapping for Membership, Roles, and History

Being recognized as an existing member does not mean every old account attribute should be copied unchanged. The migration plan should define separate rules for basic membership, registration date, public posts, reputation points, badges, paid access, private-group membership, and staff permissions. Each item has a different technical and security impact.

A basic member may receive a legacy label and the original joining date. Public posts may be imported and attached to the new profile after ownership has been established. The displayed post count should reflect the content that was actually transferred rather than an unexplained number copied from the old profile.

Reputation scores need special care. A score calculated from likes, reactions, accepted answers, attendance, or purchase activity on one platform may have no direct equivalent on another. Converting 8,000 old points into 8,000 new points can falsely imply that the two systems measure the same behavior.

A more defensible method is to preserve the historical score as a labeled legacy value or convert it through a published formula. Members should be able to see which information is historical and which was earned on the new platform. Paid membership requires reconciliation with the billing record. The migration should identify the plan, payment status, remaining access period, renewal arrangement, and areas the member is entitled to enter. A visible “paid member” label is not enough when the expiry date or recurring charge is wrong.

Moderator and administrator roles should never transfer solely because the old profile displayed a badge. The operator should review the current staff list and decide which responsibilities still exist on the new platform. Permission systems are platform-specific. Discourse, for example, manages access to categories through groups and associated permissions. A staff title from an earlier forum does not automatically describe which groups or protected areas the person should access after migration.

A practical mapping document can specify that former moderators become temporary migration reviewers, current paid members enter a restricted subscriber group, verified long-term members receive a legacy badge, and inactive historical staff return as ordinary members unless their roles are formally renewed.

This avoids treating every old privilege as permanent property. It also prevents someone who moderated the community years ago from regaining access to private reports, member records, or administrative controls without current authorization.

Duplicate Accounts and Impersonation Disputes

Account duplication is common during migration. A member may create a new profile before the official claim system opens, forget that an invitation was already accepted, or use separate accounts for different email addresses.

Duplication can also be deliberate. Someone may reserve the nickname of a well-known moderator, copy another member’s avatar, or create an account designed to look like the original profile.

A matching nickname should never be treated as conclusive proof. GitHub’s impersonation policy identifies deceptively similar usernames, copied profile information, and unauthorized use of another person’s credentials as possible impersonation behavior. It also notes that a similar username alone does not establish impersonation without considering the surrounding context.

The community should reserve important staff and organizational names before public registration begins. Other old usernames can be held temporarily during a stated claim period when the source database is reliable enough to support that process.

A reservation does not have to last forever. The migration policy might hold eligible names for ninety days, after which unclaimed names are released under the new platform’s naming rules. Members should be told about this deadline in advance.

A dispute process should examine control of the old account, not simply which person registered first on the new platform. If one claimant can authenticate through the old profile and another only has the same display name, the authenticated claimant has the stronger connection to the historical identity.

The administrator may temporarily restrict both new accounts while the case is reviewed. During this period, neither account should use transferred moderation rights, private access, paid benefits, or imported authorship.

Account merging also requires proof. Similar display names and matching profile images do not establish that two accounts belong to the same person. The operator should verify control of both profiles and explain what will happen to posts, messages, badges, notification settings, and membership time.

A merge should identify one surviving profile. The other account can be disabled or retained as a redirect where the platform permits it. Members should stop posting from both accounts once a review begins, since continued activity makes the final history harder to reconcile.

The platform should not promise that every historical username will be restored. Some names may be reserved words, conflict with platform policies, contain unsupported characters, or already belong legitimately to an unrelated user. GitHub’s username policy provides one example of a service that does not automatically release or transfer a username merely because it appears inactive.

A verified legacy badge, an old-name field, or a temporary suffix can preserve continuity without forcing the platform to resolve every naming conflict in favor of the historical holder.

Member Preparation Before the Old Platform Closes

Members should not wait until the old service becomes inaccessible. Before the shutdown date, they should update the registered email address, review recovery methods, save the migration announcement, and record the URL or internal identifier of the old profile.

They should also export any material the migration notice says will not be transferred. This may include private messages, bookmarks, saved drafts, blocked-user lists, uploaded files, or personal notes.

Not every platform can move every type of data. Mastodon, for example, explains that an account move can transfer followers where supported, but posts do not move automatically. Other data, including follows, blocks, mutes, and bookmarks, requires separate export and import steps.

Members should therefore read the scope of the transfer rather than assuming that “account migration” means a complete copy of the former profile.

Migration emails also create an opportunity for phishing. Members should open claim links only from the domain and channels announced by the community. Moderators should never request an old password, two-factor authentication code, recovery code, or complete payment-card information.

Where the migration notice has been reposted across forums or social networks, How to Find the Original Source of Information Repeated Across Multiple Communities can help members locate the operator’s first announcement instead of relying on copied instructions that may be incomplete or fraudulent.

After claiming the new profile, the member should review the joining date, imported posts, role, group access, paid-membership expiry, and any content attributed to the account. Errors should be reported during the published correction period.

Rejected Claims and Manual Review

A failed automated claim can represent two different problems. The account may be ineligible under the migration rules, or the claimant may have failed to prove ownership of an eligible account.

An eligibility appeal should address the published rule. The member might show that the account existed before the record date, belonged to an eligible member type, or held a qualifying paid plan.

An ownership appeal should address the connection between the claimant and the old account. Useful information may include the old profile ID, registered email, migration-token history, account-controlled verification action, or matching payment record.

The appeal form should explain what evidence is accepted and which information should never be submitted. Members should not post private documents in a public help thread.

Higher-risk claims should receive human review. A moderator-role dispute, duplicate paid membership, or claim involving private-area access deserves more scrutiny than a request to correct a public joining date.

Every manual decision should leave an internal audit record showing the old account involved, the benefit requested, the evidence used, the reviewer, and the result. Security logging guidance from OWASP emphasizes the role of event records in investigating significant account and security activity.

Account-recovery events should also generate a notice to the member through an existing trusted contact method. Current NIST guidance requires notifications following account recovery so that a legitimate subscriber has a chance to detect fraudulent recovery activity.

The evidence should be removed or anonymized after the appeal and any defined challenge period are complete, unless another lawful reason requires retention. The decision record can remain without preserving unnecessary personal documents.

A successful migration policy does not attempt to recreate every feature of the former platform. It establishes who controlled each eligible old account, transfers only the rights that have a defined equivalent, and provides a predictable route for duplicates and disputes.

Existing-member status should come from an official record and a secure claim, not from who tells the most convincing story or registers the old nickname first. When eligibility, ownership, role mapping, and impersonation review are handled separately, the new community can preserve its history without carrying old security weaknesses into the new platform.