iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Move organizational email in stages: inventory everything in scope, confirm the destination can migrate it, copy and reconcile the data while the old service remains available, then change DNS mail routing and validate the new service before decommissioning the old one. The exact steps depend on the providers and migration tool; moving messages alone may not move calendars, contacts, archives, or shared-mailbox access.
Decide what “European” means for your organization
First identify the requirement you are trying to meet. A provider’s headquarters, the region where live mail is stored, the location of backups, support access, subprocessors, and international data transfers are different questions. Ask the provider to address each one in writing and review the contract and transfer safeguards.
Europe is not the same as the European Union. For example, Infomaniak says the cited kDrive services host data in Switzerland and describes compliance with GDPR and the Swiss nFADP. Switzerland is in Europe but is not an EU member state. Those provider statements and a hosting location do not, by themselves, establish that a customer’s email arrangement complies with its legal obligations.
Recommended Free Tools
Likewise, the European Data Protection Supervisor’s decision concerning the European Commission’s use of Microsoft 365 addressed EU institutions under Regulation (EU) 2018/1725 and specified data transfers. It ordered specified flows suspended effective 9 December 2024. That decision is not a blanket finding that private organizations using Microsoft 365 violate the GDPR.
#1 Best Overall
Inventory the service before choosing a migration method
Make a user-by-user inventory, and list the data and services that people rely on. A migration plan that counts only inbox messages can leave important organizational information behind.
- Accounts and routing: users, aliases, distribution groups, shared mailboxes, delegated access, and addresses used by applications or external services.
- Mailbox content: mail folders, archives, unusually large mailboxes, and messages subject to legal holds or retention requirements.
- Other workloads: calendars, contacts, tasks, rules, and any collaboration data the organization expects to move.
- Access and dependencies: administrator roles, authentication, desktop and mobile clients, identity systems, endpoint policies, and third-party integrations that send or receive mail.
- Operational requirements: recovery and retention needs, acceptable disruption, the period users need access to the old service, and who will approve the cutover.
For every category, record whether it must be migrated, exported separately, retained in the source, or intentionally left behind. Confirm that the destination supports the required mailbox types and workloads before committing to a method.
Check the destination and migration coverage
Ask the prospective provider how it supports migration from your actual source—not simply whether it “supports email migration.” Verify coverage for messages, folders, contacts, calendar events, tasks, archives, shared mailboxes, and delegated access. Also confirm how it handles large mailboxes, failed items, incremental synchronization, exports, retention, and recovery.
Compare candidates on the areas that affect your organization’s day-to-day service and risk:
- Supported source services and migration method, including whether a provider, administrator, or partner must perform the work.
- Live-data, backup, support-access, and subprocessor locations, plus applicable transfer arrangements.
- Authentication, identity, endpoint management, and application integrations.
- Mail delivery controls, DNS administration, retention, recovery, and export options.
- Recurring service and migration costs, documented in the contract.
Do not treat “European” or “sovereign” as a complete answer to data-location or legal questions. The reviewed provider information does not establish a comprehensive feature or price comparison across European email services, so assess each candidate against your own requirements rather than assuming one is a turnkey fit.
Example: Microsoft 365 to Proton
Proton documents an Easy Switch for Business workflow for moving from cloud-hosted Microsoft 365. Its documented scope includes emails, contacts, and calendar events. The process requires administrator roles in both services and access to the organization’s domain provider. Confirm current prerequisites and exact coverage with Proton before scheduling the migration. Proton is Swiss; Switzerland is not an EU member state.
Rank #4
Do not assume every Microsoft migration route moves the same data
Microsoft’s generic IMAP migration moves messages from mail folders; it does not migrate contacts, calendars, or tasks. Microsoft documents a separate Google Workspace migration path that can include mail, contacts, and calendars when its prerequisites are met. These are Microsoft-specific routes and do not establish what another destination’s tool can import.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePrepare accounts, access, DNS, and users
- Provision the destination. Create the organization’s tenant or service, required mailboxes, aliases, groups, and shared mailboxes. Verify the custom domain and confirm that target accounts are ready before copying data. Microsoft’s generic IMAP workflow, for example, requires target mailboxes to exist and source mailbox access to be available.
- Confirm administrative access. Identify the source and destination roles, mailbox permissions, credentials or authorization method, and domain registrar or DNS-host access the migration requires. Use provider-specific instructions rather than applying another provider’s procedure.
- Document the existing setup. Record current mail routing and relevant DNS records, along with the services that depend on the domain. Obtain the destination’s required MX and other mail-authentication records before the cutover.
- Plan user communications. Tell staff what is included, when the move will occur, how to access the new service, whether client settings or passwords will change, and how to report missing messages or access problems. Explain that duplicate or delayed messages may occur during a transition if that is possible with your chosen method.
- Set a cutover and recovery plan. Name the person authorized to change DNS, the checks that must pass before the change, the person who will monitor delivery, and the conditions for pausing or reversing the cutover.
Run a pilot, then migrate and reconcile the data
Test representative accounts first
Start with a small group that includes ordinary users as well as complex or unusually large mailboxes. Test the complete workflow, including account access, mail flow, calendar and contact use, and any business-critical integrations. Resolve problems with permissions, unsupported items, or client setup before expanding to the organization.
Track what copied—and what did not
Monitor each mailbox’s migration status. Compare source and destination counts, date ranges, folder structure, and samples of important messages. Check calendars, contacts, archives, rules, shared mailboxes, and delegated access separately; a successful mailbox-message transfer does not prove those other items arrived.
Microsoft’s 2024 documentation for its own IMAP migration tool states a maximum of 500,000 items per user mailbox, with email migrated newest to oldest, and a maximum message size of 35 MB. These are limits of that Microsoft tool, not general email-migration standards. Microsoft also warns that archival or messaging-records policies can cause items to be reported as missing. Investigate apparent gaps against the applicable policies and the migration logs rather than assuming every discrepancy is data loss.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Change MX records only when the destination is ready
The domain’s MX record determines where incoming email is routed. Changing it is the mail-flow cutover, not a substitute for copying mailbox data. Keep the source service available while migration and validation are underway.
- Confirm readiness. Check that destination accounts are provisioned, the pilot passed, required content has been reconciled, and the provider’s DNS instructions are available.
- Update the domain’s DNS records. At the organization’s DNS host, replace or adjust the MX records as directed by the destination provider. Add or update the other records it specifies for mail authentication and service verification. Do not guess record values or blindly reuse old settings; follow the destination’s current instructions.
- Test mail flow. Verify incoming and outgoing messages, internal delivery, aliases, shared mailboxes, spam controls, and sending by critical applications. Check that desktop and mobile clients connect as expected.
- Continue synchronization if supported. If the migration method can sync changes made during the transition, keep it running until you have confirmed that new mail is arriving at the destination and the remaining checks pass.
- Close the migration only after validation. Microsoft’s IMAP guidance places the MX change after migration and says to stop synchronization only after confirming that mail is routed to the target. Treat this as guidance for that Microsoft workflow; other providers may use different procedures.
Close out without losing access or records
Do not shut down the source as soon as MX records change. Keep it available until the organization has verified routing and content, resolved migration exceptions, and completed the checks required by its own retention and recovery policies.
- Retain a controlled, read-only source archive if legal, retention, or recovery needs call for one.
- Document the final routing, account changes, migration exceptions, and any data deliberately left in the source.
- Revoke temporary migration permissions and credentials when they are no longer required.
- Confirm the destination’s backup, recovery, and retention arrangements against the organization’s requirements.
- Decommission the old service only after the accountable owners have approved the result and all applicable obligations are met.
There is no universal retention schedule for this move. The organization must apply its own legal and operational requirements before deleting source data or ending the old service.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
