Moving email providers is easy. Moving your identity is the hard part.

Open a new Proton, Fastmail, Tuta, or custom-domain mailbox and importing old messages feels like the migration. It is not. The harder migration begins when you ask one question: what still depends on the address I want to retire?

Recent privacy-community discussions describe people facing hundreds of accounts, roughly 250 inconsistent provider flows, and migrations stretching across months. The common advice is sensible—keep forwarding enabled, inspect a password manager, and change a few services each day—but it leaves coordination to memory or a spreadsheet.

One address, two separate migrations

Provider tools such as Proton Easy Switch can import email and contacts. That solves continuity of communication. It does not update your GitHub login, banking alerts, health portal recovery address, streaming subscription, airline profile, or every site where you chose “Sign in with Google.”

An old email usually plays several roles at once:

• Login identifier: the string entered before a password or passkey.
• Recovery channel: where reset links and account warnings arrive.
• Notification route: receipts, policy changes, billing failures, and security alerts.
• Federated identity: a Google, Microsoft, Apple, or other provider connection.
• Ownership evidence: an address support teams may use to verify a historical account.

Forwarding covers some notifications. It does not remove any of these dependencies, and it stops helping when the old provider closes, an employer disables the address, or a custom alias is deleted.

Start with an inventory that excludes secrets

A password manager is often the best source of domain names, but its native export is the wrong file to place into a migration tracker. It may contain usernames, passwords, notes, one-time password seeds, or recovery information.

Create a redacted list containing only service names, domains, URLs, and broad categories. A safe inventory might look like:

name,domain,category
Google Account,google.com,identity
Chase,chase.com,finance
GitHub,github.com,work
Netflix,netflix.com,entertainment

Mailshift deliberately rejects imports with credential-bearing column names. That constraint matters: an account list is sensitive, but it should never become a second password vault.

Do not migrate alphabetically. Work from risk.

If the old inbox vanished tomorrow, losing a streaming receipt would be annoying. Losing your primary identity provider or financial recovery path could lock you out of everything below it. Work in this order:

1. Identity roots: Google, Apple, Microsoft, primary password manager.
2. Money: banks, payment processors, investments, tax accounts.
3. Government and health: identity portals, insurance, pharmacy, medical records.
4. Security infrastructure: domain registrar, cloud hosting, code repositories, 2FA services.
5. Work and paid tools: collaboration, storage, subscriptions with valuable data.
6. Shopping, social, and entertainment: lower-risk accounts and long tail.

Blocked accounts should stay visible near the top. “Support is reviewing my request” is not completion; it is a migration state.

Treat every change as a verification gate

Seeing the new address in a profile is weak evidence. A safe handoff proves that the complete path works. Track these gates separately:

This sequence prevents a common failure: removing the address you still control before discovering the replacement cannot log in or receive recovery messages.

Why this workflow should stay local-first

Even without passwords, an inventory of financial, health, government, work, and social accounts reveals a detailed map of a person’s digital life. A hosted service would create another sensitive dataset and another vendor to trust.

Mailshift stores the workspace in an encrypted browser vault. The passphrase-derived key stays in memory while unlocked. The application has no backend, analytics, mailbox connection, automated login, or credential custody. Users can export an encrypted backup and a credential-free progress report.

Local-first does not mean invulnerable. A compromised device, malicious browser extension, active cross-site scripting, or weak passphrase can still expose data. Open source makes those boundaries inspectable; it does not make them disappear.

What Mailshift does not pretend to solve

Provider instructions change. Some services require access to the current inbox. Others need a trusted device, organization administrator, support ticket, or entirely new account. No universal button can safely update all of them.

Mailshift currently separates 100 source-linked playbooks from a broader catalog of 5,000 recognized popular domains. A known domain is not automatically trusted, safe, or reviewed. That distinction is visible in the product because honest uncertainty is safer than fabricated certainty.