Jo's Fedi Migration Bucket List

(An attempt at solving every single bug pertaining fediverse's migration, to make sure everyone can migrate without worries)

Some methodology, as I'll be using it a lot:

Target: Server/Account a user is migrating to.
Origin: Server/Account a user is migrating from.
Observer: Another user the user is following/follows / Server that the user has follows/followers on. This server will receive and process the Move activity.

FediDB per-version usage

Pleroma

Akkoma

Some suggestions to prevent you from losing followers when migrating.

Because of Akkoma's 24h bug, either:
- Wait 24h after setting your "old account alias" on your new account, or:
- When making the account, set your alias FIRST THING after the account is approved, before any akkoma instance even has a chance of knowing about it and fetching.
  This includes not making and/or boosting any posts from that account.

Not an exhaustive list, just a few things. Empty means I just haven't gotten to around checking it.

(Behaviour)	Mastodon	Pleroma	Akkoma
Before beginning migration, origin checks for `alsoKnownAs` on target.	Y
Make sure target and origin data is up-to-date when processing `Move` activity. (Get a successful/up-to-date/cache-bypassing fetch on each before processing `Move` activity.)		N	Y >= `3.13`
Observing instance is resillient in retries when origin/target instance is DDoSed by `Move` handling. (Retry `Move` activity until it gets proper fetches, for at least an hour or more)
Target instance pushes profile update when AKA is updated.
(Possibly) Instance handles missed `Move` when it encounters a `movedTo` attribute on profile fetch. (Unsure if this is encouraged/discouraged by the spec, but this would catch a ton of federation mishaps. Further research into what kinda behaviour this cascades into is neccecary.)