Microsoft 365 to Proton Workspace Migration: A Small-Office Walkthrough (2026)

Moving a small office from Microsoft 365 to Proton Workspace has two halves that behave very differently. The DNS cutover is the shorter half. It is a handful of records, and with the groundwork done in advance it normally avoids planned downtime. The content migration is where the time goes, because in September 2026 Microsoft 365 customers do not yet have the admin-level migration tool Google Workspace customers received in June.

This walkthrough follows the order we use for small offices, most recently a five-person design studio that moved from Microsoft 365 to Proton Workspace Standard and left Microsoft entirely. It covers what Easy Switch moves, what stays behind, the identity and shared-mailbox decisions that are easy to miss, and how to close the Microsoft side without losing data.

Does Easy Switch Support Microsoft 365 Organizations?

Not as an organization-wide migration yet. On 17 June 2026 Proton launched Easy Switch for Business, which lets an administrator migrate a whole Google Workspace organization in one guided flow. Microsoft 365 is not supported yet. Proton's announcement says: "Running Microsoft 365 instead? Stay tuned. We have a Microsoft 365 migration path planned for you this year."

Until that arrives, Microsoft 365 migrations use the standard Easy Switch Outlook import, run per mailbox. It works, but it means repeating the same steps for each user and tracking which mailboxes are done, which makes it more hands-on than the Google equivalent. When Proton ships the Microsoft path, the mailbox steps below get shorter; the identity, file, DNS and cleanup steps stay the same.

Prerequisites

How Long Does a Microsoft 365 to Proton Migration Take?

For a small office, plan on roughly a week from inventory to cutover, followed by a short acceptance period before Microsoft is closed. The sequence below is the one we follow.

A five-person office can compress this into a few days; the order matters more than the duration.

What to Inventory Before You Start

In our experience, the issues that come up during a small-office migration usually trace back to something that was not on the inventory.

List everything that sends mail as your domain. Scanners using SMTP, a website contact form, invoicing software, a CRM, a booking tool. Anything that authenticates to Microsoft's SMTP service stops working when the tenant closes, and anything that sends through a third-party service must stay in your SPF record. Our guide to business email landing in spam covers the authentication side.

List where files actually live. In the design studio's case the answer was several places — more than one cloud service plus local drives — which is common in creative offices. Each source is its own small migration.

Note who uses which apps. If anyone depends on macro-driven workbooks, pivot tables or PowerPoint, decide now whether they keep a standalone Microsoft 365 Apps licence. The studio did not need one; many offices do.

Shared mailboxes, lists and role addresses

Proton has no shared-mailbox object. Proton Groups, available on Workspace plans with a custom domain, are distribution lists: mail sent to the group address is forwarded to each member. That is useful, but it is not a shared inbox with shared sent history and delegation. Decide each object's replacement before cutover:

Identity dependencies

Leaving Microsoft 365 also means leaving Microsoft Entra ID as the office's identity system. Check each of these before the tenant closes:

• "Sign in with Microsoft" on third-party apps. Any SaaS account that uses the work Microsoft account for sign-in needs a password or another sign-in method set first, or the user may lose access when the Microsoft account is disabled. Our Proton Mail for Business review includes the full pre-migration identity audit we run with clients.
• Windows devices joined to Entra ID or signed in with work accounts. Plan how each PC will be signed in afterwards, and export any BitLocker recovery keys stored in Entra before the tenant goes.
• Intune, Defender and Conditional Access, if used. Unenroll devices deliberately rather than letting policies lapse.
• Microsoft Authenticator entries tied to work accounts, which stop being useful after the move.
• Proton account security. Each user sets up two-factor authentication and a recovery method in Proton before cutover.

Proton's admin model is also worth explaining to staff. Organization users are non-private by default, which lets administrators access their mailboxes, and on Workspace Standard and Premium administrators can use "Sign in to a user" to reach a member's Drive files. Proton as a provider cannot read that content; your own administrators can. For continuity that is usually what a business wants, but it should be stated plainly, and any user set to private changes what an administrator can recover later.

Step 1: Set Up Proton Without Touching Mail Flow

Everything in this step happens while MX still points to Microsoft, so users notice nothing.

1. Buy the plan and create the organization. The design studio went on Proton Workspace Standard: $12.99 per user per month on annual billing or $14.99 month-to-month, 1 TB per user. If you are deciding between Standard and Premium, our Standard vs Premium comparison covers retention rules, storage, and when the upgrade is worth it. For smaller or mail-only setups, our Proton plans guide explains where the other tiers fit.
2. Add the domain in Proton and publish the verification TXT record (protonmail-verification=…). It coexists with Microsoft's verification record.
3. Create each user with their address on your domain, plus the aliases and groups decided in the inventory.
4. Publish the three DKIM CNAME records (protonmail._domainkey, protonmail2._domainkey, protonmail3._domainkey, targets copied from Proton's domain settings). They do not conflict with Microsoft's selector1 and selector2 records.
5. Lower the TTL on your MX records to 300 seconds or your DNS host's minimum, at least a day before cutover.

Step 2: Grant Consent, Then Import Each Mailbox

Easy Switch connects to Microsoft through a sign-in and permissions prompt. Many tenants block ordinary users from approving a third-party app's access to mail, so the first user to try sees an approval request.

If your tenant blocks user consent, have an appropriately privileged Microsoft Entra administrator review Proton's requested permissions and grant tenant-wide consent. In most small tenants that is the Global Administrator; Microsoft also allows roles such as Cloud Application Administrator and Application Administrator to grant consent for most permissions. Microsoft describes tenant-wide consent as a sensitive operation, so check the publisher and the permissions requested before approving.

Then, for each user:

1. In the user's Proton account, go to Settings → All settings → Import via Easy Switch and choose Outlook.
2. Sign in with that user's Microsoft 365 credentials.
3. Select the data to import. For the calendar, choose to merge into the user's existing Proton calendar unless you want a separate one; there is no merge tool afterwards.
4. Deselect Microsoft system folders with no Proton equivalent, such as Snoozed.
5. Start the import and move to the next mailbox.

Proton states that Easy Switch can run transfers from up to two different accounts at the same time, with only one transfer at a time from the same account. Imports run in the background, so working through the list two mailboxes at a time is the practical rhythm for a small office.

Run the administrator's own mailbox first and check folder structure, older messages with attachments, recurring meetings and contacts before importing anyone else.

Step 3: What Easy Switch Leaves Behind

Each item is small. Together they are an hour or two of work for a five-person office, and collecting screenshots of rules, signatures and calendar shares beforehand reduces support questions on the first day.

Step 4: Move the Files

Easy Switch does not handle files. The route from OneDrive and SharePoint is download, check, upload:

1. Download in batches. Microsoft limits browser downloads to 10,000 files and 250 GB per file. Divide larger libraries into smaller, named batches rather than selecting everything at once.
2. Unzip and check each batch on a staging drive, comparing file counts with the source.
3. Upload through the Proton Drive desktop app by placing files in its folder, into a folder layout agreed before anyone starts. Agreeing the layout first prevents a second reorganisation later.

Files from other services and local drives follow the same staging pattern. Our Dropbox to encrypted cloud storage guide covers the Dropbox side.

What does not survive the file migration

A file migration moves bytes. It does not move the Microsoft structure around them:

Three things about Proton Drive are worth telling staff before they go looking for files:

• Search covers filenames, not file contents. Proton Drive search currently matches filenames only, and in the web app it returns files in My files; items under Shared with me do not appear in results. Clear folder and file naming matters more than it did on OneDrive.
• Word and Excel files remain usable. Proton Docs opens .docx and exports to .docx or .pdf; Proton Sheets imports and exports .xlsx, .csv and .tsv. Opening a Word file in Docs creates a new Docs copy rather than changing the original.
• Administrators can reach users' Drive files, as described in the identity section above.

Step 5: The DNS Cutover

Go/no-go before changing MX

Change MX only when all of these are true:

• Every mailbox import has finished and the pilot user has confirmed mail, calendar and contacts.
• Proton shows the domain verified and all three DKIM records valid.
• Every user can sign in to Proton and has two-factor authentication set up.
• The new SPF record is written, including every third-party sender from the inventory.
• A copy of the current Microsoft DNS records is saved.
• Staff know the cutover time and where to report problems.

The records

There must be only one SPF record for the domain.

DMARC needs a separate decision. Proton recommends p=quarantine for most domains, and that is a sensible destination. During a migration, though, the safer sequence is:

• If a DMARC record exists, keep it and adjust it rather than replacing it. Do not weaken a policy that is already enforced.
• Add aggregate reporting (rua=) if it is missing, so you can see what is passing.
• Confirm SPF and DKIM alignment for Proton mail and every third-party sender first.
• If the domain has no DMARC record yet, start at p=none, review the reports, then move to quarantine.

Our DMARC guide for small businesses covers the policy options.

After the MX change, send test messages from outside accounts to each user, reply from Proton, and check that SPF, DKIM and DMARC pass in the headers. Proton notes that DNS changes can take minutes to hours depending on TTL, and that some platforms keep old DNS information for 1–3 days, so some senders will keep delivering to Microsoft for a while. Monitor both systems during that period.

Rollback

Keeping Microsoft licensed and the domain in the tenant until acceptance is what makes rollback possible. If a significant problem appears, restore the saved MX, SPF and Autodiscover records; mail returns to Microsoft once DNS propagates. Anything delivered to Proton in the meantime has to be moved back by hand, so the earlier the decision, the smaller the cleanup. The Proton DKIM records can stay in place; they do not affect Microsoft.

Step 6: Accept, Then Close the Microsoft Side

Acceptance checklist for each user

• Receives mail from an external address and replies successfully.
• Folders, older messages and attachments are present.
• Calendar shows recurring meetings; shared calendars are re-shared.
• Contacts are complete.
• Filters and signature are rebuilt.
• Files are in the agreed Proton Drive folders and open correctly.
• Phone and desktop apps are signed in to Proton and signed out of Microsoft.
• Two-factor authentication and recovery are set up.

Before closing anything, check each Microsoft mailbox for messages that arrived during propagation, and move anything that matters. Meeting invitations accepted during that window are worth checking specifically.

Closing down Microsoft

1. Remove the domain from the tenant. Microsoft blocks removal until nothing uses it: change users' sign-in names to the .onmicrosoft.com domain, remove the domain from shared mailboxes, groups, distribution lists and aliases, then remove it under Settings → Domains. Microsoft estimates about five minutes for a simple tenant and up to a day when many objects reference the domain.
2. Remove leftover Microsoft DNS records, such as the selector1/selector2 DKIM CNAMEs, enterpriseregistration and enterpriseenrollment CNAMEs, and Teams/Skype SRV records.
3. Cancel the subscription rather than deleting it. Do not assume a fixed timeline: Microsoft's lifecycle depends on how the subscription was purchased and ended. An annual subscription with recurring billing turned off enters Expired on its end date; a monthly subscription cancelled within the cancellation window skips Expired and moves straight to Disabled, where users lose access and only admins can reach data. Microsoft says remaining data may be deleted after 90 days and no later than 180 days after cancellation, and that explicitly deleting a subscription skips these stages and deletes SharePoint and OneDrive content immediately. Check the dates shown in your Microsoft 365 admin center before relying on them.

Keep the administrator account's access until the data period ends; it is the fallback if someone discovers a missing file in the first month. Our IT handover checklist is a useful final pass for documenting the new admin credentials, recovery codes and DNS host access.

Which Offices Is This Migration Right For?

The move fits offices whose work runs through email, calendar and files rather than through the Microsoft ecosystem around them — design studios are a typical example, with creative-suite working files and email-led client communication. Workspace Standard also includes Proton VPN and Proton Pass, which matters when an office would otherwise pay for those separately. Microsoft 365 remains the better fit where Teams, SharePoint workflows, heavy Office use or Intune are central to how the office works. For the full feature and cost picture, see our Proton Workspace review.

Proton offers a 14-day free trial for new business customers (up to 10 users, on a new account created through the trial flow), followed by a 30-day money-back guarantee with a prorated refund once the paid subscription starts. That is enough time to run the pilot mailbox in Step 2 before committing the rest of the office.

If you would rather not run the migration yourself, iFeelTech scopes and handles Microsoft 365 to Proton moves for small offices, including DNS, mailbox imports, file transfer and Microsoft 365 cleanup.

Related Resources

• Proton Workspace vs Microsoft 365 — Costs at 5, 10 and 25 seats, feature gaps, and which businesses should switch.
• Google Workspace vs Proton Workspace — The same decision for offices on Google, where Easy Switch for Business already handles mailbox migration.
• Proton Mail for Business Review — Mail Essentials pricing and the identity audit to run before any cutover.
• Proton Drive vs Google Drive for Business — How encrypted storage changes search, sharing and admin access.
• DMARC for Small Businesses — Setting a DMARC policy after the cutover.