Mimecast or Proofpoint to Defender for Office 365 Migration moves your email filtering from a third-party secure email gateway onto the Microsoft Defender for Office 365 protection you are already licensed for — Plan 1 inside Microsoft 365 Business Premium, Plan 2 inside Microsoft 365 E5. IT Partner follows Microsoft's published three-phase migration path: Defender preset security policies stood up for a pilot ring while the gateway stays in front, Enhanced Filtering for Connectors so Defender sees real sender IPs during the coexistence window, quarantine notifications and user communications prepared, then a staged MX cutover per domain with a documented rollback, and tuning on live traffic across the two-week window. You also get something most migration pitches leave out: a written trade-off document that records honestly what you give up leaving a dedicated gateway — continuity features, the vendor archive, some policy granularity — and what consolidation buys back. Archive data migration is explicitly out of scope and quoted separately.
If your tenant runs Microsoft 365 Business Premium or E5, you already own an email security stack: Defender for Office 365 Plan 1 comes with Business Premium and Plan 2 with E5. Organizations that adopted Mimecast or Proofpoint years ago — often before those licenses existed in their tenant — are now paying twice for overlapping capability: a per-seat gateway fee for filtering, plus Microsoft licensing that includes filtering they never switched on. Consolidating onto Defender for Office 365 is a named cost-and-complexity play, and it is also a real migration with real failure modes, which is why this engagement follows Microsoft's own published three-phase path — prepare, set up, onboard — rather than a big-bang MX flip. The mechanics matter. While your gateway sits in front of Microsoft 365, Defender cannot see the true sending infrastructure unless Enhanced Filtering for Connectors is configured — without it, every message appears to come from your gateway's IP addresses and Defender's verdicts are unreliable. So the engagement runs a deliberate coexistence window: the gateway keeps filtering in front, Enhanced Filtering lets Defender evaluate the same mail accurately, preset security policies (Standard, with Strict where your risk profile calls for it) protect an expanding pilot ring, legacy bypass rules that stamp inbound mail as safe are unwound for pilot users, and false positives and misses are tuned on evidence. Only when the pilot data is clean does the MX record cut over to Microsoft 365, domain by domain in an agreed window, with rollback documented — pointing MX back at the gateway, which is one reason we insist you keep the gateway subscription active until cutover is verified. And because leaving a dedicated gateway is a trade, not a free upgrade, the deliverable this page is named for is the trade-off document. Mimecast and Proofpoint are capable platforms; you may be using continuity, archiving, or policy features that Defender for Office 365 does not replicate one-for-one. The comparison table below is the summary; the engagement version is written against your actual configuration, so the decision to consolidate — or to deliberately keep a vendor component such as the archive — is made with eyes open. Archive data itself never moves in this engagement: exporting or migrating years of journaled mail out of a gateway archive is its own project and is scoped separately. Outbound authentication is a common companion gap: pointing MX at Microsoft changes nothing about SPF, DKIM, and DMARC, but gateway removal is the natural moment to fix them — that is the separate DMARC, DKIM, and SPF Email Authentication Implementation engagement. If you have no gateway and simply want Defender for Office 365 configured well from scratch, Microsoft Defender for Office 365 Implementation is the right page; for a lighter hardening of Exchange Online Protection defaults, see Additional Spam and Phishing Protection.
The honest trade-off. Leaving a dedicated gateway is a trade, not a free upgrade — this is the summary of what consolidation buys and what it costs, written without vendor spin in either direction. Your engagement version is produced against your actual gateway configuration and signed off before the MX moves.
| What you give up | What you get back | |
|---|---|---|
| Licensing spend | A vendor relationship you may still want pieces of — if the archive or continuity component is essential, that part of the subscription may deliberately survive the filtering migration. | The per-seat gateway filtering fee ends. Filtering runs on Defender for Office 365 licenses you already own — Plan 1 in Business Premium, Plan 2 in E5 — instead of being paid for twice. |
| Email continuity | Gateway continuity features that provide a separate mail path during a Microsoft 365 outage. Defender for Office 365 has no equivalent standalone continuity mailbox — this is the single most common reason to hesitate, and we put it in writing rather than gloss over it. | One less hop in the mail path to fail, misroute, or expire a certificate. You rely on Microsoft 365's own platform resilience, and the trade-off document records that continuity decision explicitly so it is made, not defaulted. |
| Archiving | New mail stops accruing to the gateway's cloud archive once journaling to it ends. Years of already-archived mail remain in the vendor's store until exported — that data does not move in this engagement. | Retention going forward consolidates into Microsoft Purview retention policies and Exchange Online archiving — one policy engine across mail, Teams, and SharePoint. Migrating the historical archive is scoped separately as its own project. |
| Policy granularity | Some gateway-specific controls do not map one-to-one: fine-grained per-sender routing and stationery, managed graymail and newsletter digests, and policy shapes your admins have tuned for years. | Preset security policies that Microsoft maintains as the threat landscape shifts, custom policies only where you genuinely need a delta, and bulk-mail thresholds tuned per mailbox — fewer hand-built rules left to drift. |
| Consoles and signal | A second, independent filtering vendor in front of Microsoft — some organizations value the two-vendor defense-in-depth posture for its own sake, and that is a legitimate position. | One console: mail, endpoint, and identity signal together in the Microsoft Defender portal, with Threat Explorer for investigation. With MX pointed at Microsoft, Defender sees original sender IPs and evaluates SPF, DKIM, and DMARC natively — no connector workarounds. |
No vendor disparagement is intended and none is needed: Mimecast and Proofpoint are capable platforms. The case for this migration is economic and operational — not paying twice for overlapping capability — and where a vendor component is genuinely load-bearing for you, the trade-off document will say keep it.
We do not publish comparative catch-rate claims for any filtering product. The coexistence window exists precisely so you can see Defender's verdicts against your own live mail before the MX moves — your data, not a vendor benchmark.
Inventory the gateway configuration and export its policy set, verify Defender for Office 365 licensing and plan features, map gateway policies to Defender equivalents and flag the gaps for the trade-off document, agree the pilot ring, cutover windows, and communication plan.
Configure Enhanced Filtering for Connectors so Defender sees true sender IPs behind the gateway, assign preset security policies to the pilot ring, unwind legacy safe-stamping transport rules for pilot users, and stand up quarantine policies, notifications, and user-reported message settings.
Expand the pilot ring in stages while the gateway remains in front. Review Defender's verdicts against live mail in Threat Explorer, tune impersonation, spoof, and bulk thresholds, and resolve false positives and misses on evidence. The trade-off document is drafted and reviewed with you in parallel.
Extend preset policies org-wide, then cut MX to Microsoft 365 per domain in the agreed window with rollback documented. Verify inbound and outbound flow, watch quarantine and transport queues closely through the first days, and keep the gateway subscription active until verification completes.
Post-cutover tuning reading on direct-MX traffic, final trade-off document sign-off, and handoff: the decommission checklist, open allow/block entries with owners, and what to monitor in the Defender portal going forward.
No outage is planned and none is expected. The MX change is a staged DNS update per domain: mail simply starts arriving at Microsoft 365 directly instead of through the gateway, and during propagation both paths deliver. Defender policies have been protecting your users for days by that point, tuned on live traffic during coexistence — the cutover changes the mail path, not the protection. Rollback is pointing MX back at the still-active gateway.
Either works — they carry different Defender for Office 365 plans. Business Premium includes Plan 1: Safe Links, Safe Attachments, and anti-phishing with impersonation protection. E5 includes Plan 2, which adds Threat Explorer, automated investigation and response, and Attack Simulation Training. We verify exactly what your licensing includes in the first days and design policies to your plan; if you sit on Exchange Online Protection alone with no Defender plan, this migration is not the right fit yet and we will say so.
Nothing, in this engagement — and that is deliberate. Your archived mail stays in the vendor's store, and the decommission checklist explicitly warns against terminating archive access before you have decided what to do with that data. Exporting or migrating years of journaled mail is its own project with its own chain-of-custody and ingestion questions, and it is scoped separately. What this engagement does change is where retention happens going forward: new mail is governed by Microsoft Purview retention and Exchange Online archiving.
Honestly: nothing equivalent. Defender for Office 365 is a filtering and protection stack, not a continuity service — there is no standalone emergency mailbox that activates during a Microsoft 365 outage. You would be relying on Microsoft 365's own platform resilience. For some organizations that is acceptable; for others with hard continuity obligations, the right answer may be keeping the continuity component of the vendor subscription while migrating filtering. That is exactly the kind of decision the trade-off document exists to record.
We will not hand you a comparative catch-rate number — vendor benchmarks in this space are marketing artifacts, and we do not invent metrics. What we give you instead is your own data: during coexistence, Enhanced Filtering lets Defender evaluate the same live mail your gateway is filtering, and we read its verdicts with you before the MX moves. You see the false positives, the misses, and the tuning — on your traffic. That evidence, not a brochure claim, is what gates the cutover.
When mail routes through a gateway before reaching Microsoft 365, every message appears to come from the gateway's IP addresses — so Defender cannot evaluate the true sending infrastructure, and its spoof, phish, and connection verdicts degrade. Enhanced Filtering for Connectors (Microsoft's 'skip listing') tells Microsoft 365 which hops belong to your gateway so filtering looks past them to the original source. It is what makes an honest coexistence evaluation possible, and Microsoft's own migration guidance treats it as required.
After — never before — three things: the MX cutover is verified on every domain, the post-cutover tuning reading is done, and you have a decision about the archive. Cancelling early is the one genuinely destructive mistake in this migration: it deletes your rollback path and can strand archived mail behind a lapsed contract. Renewal timing is worth raising in the first call; if your renewal lands mid-project, we sequence around it.
The gateway's quarantine digest disappears and Microsoft's quarantine notifications take its place — different look, same job, and the user communications we prepare cover it. Users get a supported way to report suspicious messages that routes where you want reports to go. Links in mail may show Safe Links wrapping. That is roughly the whole visible surface; mailboxes, addresses, and Outlook stay untouched.
Differently, and this is one of the granularity trade-offs we document rather than hide. Defender handles bulk mail through a bulk complaint threshold you can tune per policy, plus user-level allow and block. Gateway-style managed newsletter digests and per-sender subscription workflows do not have an exact twin. For most organizations the bulk threshold tuned during the pilot lands well; if graymail management is a feature your users actively love, it goes in the trade-off document as a named consideration before cutover.
Split architectures are technically possible and occasionally justified — an outbound DLP or encryption dependency, for instance — but they keep a hop, a contract, and a set of failure modes alive, which is usually what this migration was meant to end. If something outbound genuinely needs the gateway, we will document it in the trade-off analysis with options: replicate it in Microsoft 365, keep a narrow vendor component, or scope follow-on work. The default destination is full consolidation with MX and outbound both direct.
Removing the gateway from the inbound path does not by itself break outbound authentication, but gateway-era records often carry vendor includes and outbound-relay assumptions worth cleaning up — and if the gateway signed DKIM on your behalf outbound, signing needs to be verified as Microsoft 365's. We check that your mail still authenticates correctly after cutover. A full authentication build-out — SPF restructuring, DKIM across all sending services, a monitored DMARC enforcement ramp — is the separate DMARC, DKIM, and SPF implementation engagement, and gateway removal is a natural moment to do it.
It is Microsoft's published path — the Defender for Office 365 documentation describes exactly this three-phase migration from a third-party protection service: prepare, set up with Enhanced Filtering and a pilot on preset policies, then onboard with an MX cutover once the pilot proves out. Our engagement adds the parts Microsoft's generic guidance cannot: your gateway's specific policy mapping, the user communications, the contract-timing guardrails, and the written trade-off document.