Move the service. Keep control of the business.
A Proton migration should be staged, reversible and boring. Heroic cutovers are poor planning with a better soundtrack.
Use the runbookVerify current terms directly with Proton
This opens the provider's official website directly. It is not an affiliate link and SignalBridge earns nothing from the visit.
Visit Proton official siteThe runbook
1. Inventory
Users, aliases, shared mailboxes, calendars, forwarding, SMTP devices, applications, retention and recovery accounts.
2. Ownership
Confirm registrar access, DNS authority, MFA and recovery contacts.
3. Pilot
Use real users, mobile devices, desktop clients, calendars, search, files and support.
4. Import
Use supported migration tools. Validate folders, contacts, calendars and message counts.
5. Authenticate
Prepare MX, SPF, DKIM and DMARC. Record old values and rollback steps.
6. Cut over
Change routing once, monitor both systems and keep the old service available.
7. Validate
Test external delivery, aliases, reply paths, mobile clients and business applications.
8. Retire
Cancel only after imports, legal requirements and rollback confidence are complete.
Proton-specific warnings
- External email is not automatically end-to-end encrypted.
- Desktop clients using Bridge may store local copies without encryption.
- Google Workspace migrations can use Proton's supported admin-led route; other sources need the appropriate import method.
- Test scanners, CRMs and websites that send mail. A working personal inbox proves very little.
Rollback trigger
Rollback when inbound mail is failing, authentication is wrong, critical applications cannot send, or support volume exceeds the team's capacity. Pride is not continuity.
Last reviewed 19 July 2026. Verify current plans, limits and migration terms directly with the provider.
Continue with Proton
This opens the provider's official website directly. It is not an affiliate link and SignalBridge earns nothing from the visit.
Visit Proton official site