Moving to Encrypted Email: A Migration Checklist
Most failed email migrations are not cryptography failures. They fail because an address changed and nobody was told, because a recovery account still points to the old inbox, or because three years of correspondence became hard to search. A migration is a logistics exercise with a privacy component. Doing it in the right order keeps it reversible until the last step.
Table of contents
- Decide what problem the move solves
- Addresses, aliases and forwarding
- Contacts, keys and the search problem
- People outside the system
- The cutover sequence
- Plan the rollback and the failure modes
- FAQ
- Bottom line
Decide what problem the move solves
Write down one sentence before changing anything. “I want message contents to be unreadable by my mail provider” is a clear goal with a clear test. “I want to be more private” is not, and it tends to produce a pile of settings that are hard to evaluate later.
The goal determines the scope. If it is about content confidentiality for correspondence with a small group, a new address with a handful of contacts may be enough. If it is about an existing identity used for banking, employers, and government services, a full migration is a much larger project with a long tail of accounts that still send to the old address.
Addresses, aliases and forwarding
Keep the old address alive for a defined period. The cost of an extra mailbox for a while is small compared with a silently missed renewal or password reset. Set forwarding from the old address, but understand what it does to privacy: a forwarded message is a new message, and forwarding from a conventional inbox to an encrypted one does not retroactively protect the copy that sat in the old mailbox.
Check whether the new provider supports aliases or multiple addresses, and use them to separate categories of correspondence. That reduces the blast radius if one address ends up on a marketing list and gives you a cleaner way to retire the old one later.
- List every service that uses the old address as a login, not just as a contact address.
- Update recovery addresses first, before changing login addresses.
- Decide a date to stop checking the old inbox, and put it in the plan.
Contacts, keys and the search problem
Export contacts and import them before the cutover, then verify a sample rather than assuming the mapping worked. For end-to-end encryption, key discovery is a separate step: within the same provider it is often automatic, while contacts on other systems may require an exchange or a different arrangement entirely.
Search is the change people notice most. A provider that cannot read message bodies often cannot offer server-side full-text search over them, so clients index locally instead. That works well on a desktop with the full archive downloaded and poorly on a phone with a small local cache. Plan where the historical archive will live and how it will be backed up, because a local-only index makes the archive part of your backup responsibility.
People outside the system
For each group of correspondents, decide the arrangement in advance: same-provider end-to-end, a key exchange, a password-protected message, or ordinary mail for non-sensitive content. Most people do not need every message protected; they need the sensitive ones protected and an agreed way to recognise them.
A short note explaining what changed and what you need from them is more effective than a technical explanation of the cryptography. Include the new address, which topics should go there, and what to do if a message arrives that they cannot open. Expect a few weeks of mixed delivery and keep the tone practical.
The cutover sequence
- 1. Create and verify the new account, including recovery options and a second factor with a stored backup.
- 2. Import contacts and set forwarding from the old address; send a test to yourself from an outside account.
- 3. Update the accounts with recovery power: primary email on other services, financial accounts, and anything with a reset link.
- 4. Notify correspondents with the new address and the topic split.
- 5. Move the archive to its long-term home and confirm you can search it on the devices you use.
- 6. Run both in parallel for a defined period and keep a list of anything still arriving at the old address.
- 7. Retire the old address only after the incoming list has been empty for a full billing or renewal cycle.
Plan the rollback and the failure modes
Until step seven, the migration should be reversible: the old mailbox still receives mail, nothing has been deleted, and the archive exists in two places. Write down what would make you stop — for example, an account that cannot be updated because its reset link goes to the old address, or a client that cannot index the archive usefully on a phone.
Three failure modes recur. A recovery loop, where the account needed to reset the new mailbox is the one you just retired. A silent search loss, where the archive is technically present but unusable day to day. And a mixed-protection thread, where one participant believes the whole conversation is protected while another is sending ordinary mail. All three are visible early if you run both systems in parallel and check, rather than flipping everything at once.
FAQ
Can I just forward my old mail to the new encrypted account?
You can, and it is useful during a transition, but forwarding does not protect messages that already sat in the old mailbox, and it creates a new copy at each hop. Treat it as a temporary bridge, not as a privacy measure.
Will I lose search over old messages?
Often server-side full-text search changes, because a provider that cannot read bodies cannot index them. Clients commonly index locally instead, which works best where the archive is downloaded and backed up. Check this on the phone you actually use before moving everything.
How long should I keep the old address?
Long enough to cover a full cycle of statements, renewals and annual notices. Retire it only after nothing of consequence has arrived there for that period, and after every account using it as a login has been updated.
Do I need every correspondent to switch?
No. Decide which conversations need content protection and make a workable arrangement for those. Ordinary mail remains fine for non-sensitive correspondence, and a partial migration that is understood by both sides is better than a full one that quietly fails.
Bottom line
Treat an encrypted-email migration as a logistics project with a clear sentence defining what you want protected. Keep the old address alive, set forwarding as a bridge, update recovery paths before logins, tell correspondents what changed in plain language, and decide where the archive and its search index will live. Run both systems in parallel and keep the move reversible until the last step. The technology is the easy part; the things that go wrong are addresses, recovery loops, local-only search, and a thread where one person assumes more protection than the other. A written checklist with a rollback point handles all four.
If you want to compare current plans in this category, the link below goes to our own product page.