Keep a small record
of a large move.

Before: record enough to recognise the account.

Use the address reader with your public handle and save its JSON. Check the DID and reverse-handle result, not just the familiar profile image. Record the observation time. Save public links to a recent post, an older post with an image and a post with a video if your account has one. Choose examples you can recognise without downloading an entire archive to an unrelated website.

Keep account recovery on an email address you expect to retain. A disposable inbox is inappropriate for migration, security codes or long-term recovery. If you have a custom handle, note the exact spelling. If your name belongs to the current provider’s domain, expect the official flow to explain the available replacement.

Put those notes in a file you control. The purpose is not a giant checklist: it is to avoid relying on memory when one field changes and another stays the same.

During: separate waiting from failure.

Follow the migration service’s progress display and keep any reference it gives you. Do not infer a universal deadline from another person’s move. Account size and media can affect duration. Refreshing the public address reader is an observation; it does not accelerate copying or repair a stalled transfer.

If the service reports an error, keep its exact wording and the time, without recording a password or token. Check the official help entry and its linked support routes before restarting. An app showing old content is not by itself evidence that the migration service failed.

After: compare identity, then inspect content.

Read the current public address again and use the local comparison tool. If the DID differs, first check that the two files refer to the same intended account. If the DID matches and the PDS changes, record that result without claiming the full migration is complete.

Open the saved post links. For media, check that the actual image or video loads rather than counting a placeholder as success. Try the official sign-in route and the apps you rely on. A public post loading and an authenticated session working answer different questions.

Fictional example: Ren’s identity and host compare as expected, and a recent text post loads, but an old image does not. The useful report says exactly that. “Everything moved” would overstate the evidence; “the entire move failed” would also go beyond it.

Send support a reproducible description.

Record the public handle, the observation time, the affected public URL and the visible error. State whether the problem appears in a public browser view, in a signed-in app or in the migration service itself. Attach only the relevant public-address comparison if support requests it; do not add account secrets.

If a public profile behaves differently between browser sessions, WebTraceCheck can provide a separate cloud browser for that public-page check. It cannot certify copied data or repair the account. Use the symptom guide →