The scenario usually plays out like this: An organisation decides to retire from Mimecast and consolidate onto Microsoft 365. The IT department then scopes the project; a migration partner moves the whole archive across, and a few months later the mailboxes look identical to how they did before. The project however gets marked as a success, and the Mimecast contract lapses.  

Six months later, the legal team has a discovery request tied to a matter that predates the migration, and the hold that was supposed to preserve those emails isn’t there. Or a departed employee mailbox never actually made the trip out of the Mimecast archive during the migration.  

Nobody did anything wrong on purpose. It was simply a case of assuming that while the migration would move the files, the compliance would automatically follow. It doesn’t.  

This is the exact gap most migration guides don’t talk about. They’ll walk you through mailbox counts, export formats and DNS cutover in detail, because that’s the part that’s easy to plan.  

What they skip over is the part that determines whether the organisation stays defensible once Mimecast is switched off: whether every legal hold, retention rule and eDiscovery matter has genuinely survived the move, not just the emails.

The actual difference between Mimecast and Purview

The reason this needs a proper project, rather than a straight lift-and-shift, comes down to how the two platforms are actually built. 

Mimecast keeps a separate, centralised archive that sits next to Exchange. Purview archiving works differently: it extends the mailbox itself, in place. That’s not just a different interface but rather a genuine change in where the data lives. 

The way the two platforms handle retention also differs. Mimecast tends to apply one uniform retention policy, whereas Purview splits the job into two. These include (1) retention policies that apply at container level (like a whole mailbox) and (2) retention labels that apply at item level (a single email), governed by a precedence order where the longest applicable period always wins. One Mimecast policy can quietly need several coordinated policies and labels in Purview to do the same job properly. 

It is often also assumed at legal holds automatically carrier over – they don’t. Mimecast’s litigation hold keeps messages inside its own archive. Purview however treats eDiscovery holds (tied to a specific matter) and retention (an ongoing policy) as two separate things, with different rules for release. A hold must be rebuilt as an equivalent hold or label in Purview, then tested, before anyone can rely on it again. 

Compliance is usually why the move happens in the first place

The irony is the fact that organisations rarely move from Mimecast to Purview purely only for cost. Compliance is usually the actual driver, the appeal of one governance and policy set instead of two. 

But during the migration itself, especially if it drags on or Mimecast only gets partially switched off, the organisation is temporarily running compliance across both platforms at once. Holds can be split between them, and an eDiscovery search must cover two repositories to be complete. That’s the phase where things quietly get worse before they get better and rushing the decommission date to escape it just locks the fragmentation in place instead of resolving it. 

Top tips for a clean cutover 

• Pull the full list of live holds first

Include anything tied to a matter that’s technically closed but was never formally released as those are the ones that are forgotten easiest.  

• Don’t trust a hold until you’ve tested it

Rebuild the equivalent in Purview and confirm it actually preserves and surfaces content before a live matter depends on it. 

• Map retention policy by policy, not in bulk

Purview’s precedence rules mean the same settings can produce a different real-world outcome than you expect. 

• Check your licence tier before you scope the project, not after

E3 covers the core archiving, while E5 is what is needed for retention labels and full eDiscovery.  

• Don’t forget the leavers

Inactive mailboxes for departed staff need the same discoverability in Purview that they had in Mimecast. 

• Trace every DNS record and legacy mail route that touches Mimecast

This is done to ensure deliverability doesn’t quietly break mid-cutover. 

• Let the export timeline set the decommission date, not the other way round

Mimecast throttles exports, and rushing against that is where “hostage fee” horror stories come from. 

• Get compliance and legal sign-off before the contract lapses, not after

Run the eDiscovery searches and hold tests while you still have both platforms to compare against. 

Where it usually goes sideways

A few patterns are likely to come up repeatedly:  

• Team assuming the checklist is optional because the data migration itself seems clean and successful, 

• Locking in a decommission date before anyone has tested a single hold, 

• A DNS record or legacy mail route nobody remembered, surfacing as a deliverability gap weeks, or even months later,  

• A license tier that doesn’t cover the eDiscovery capability everyone assumed was included, 

• eDiscovery has been running across two platforms for months longer than planned, because the readiness work never happened upfront.  

Why NBConsult approaches this differently

As NBConsult, a division of Cyberlogic, we have run enough of these migrations to know that the technical move and the compliance move are two different projects that happen to look like one. So, the engagement doesn’t start with moving data but rather starts with an inventory: what’s actually configured in Mimecast today, what holds are live, which retention rules apply, and what it needs to look like once it’s rebuilt in Purview. 

From there, the migration itself is sequenced by date range rather than run as one big transfer. That keeps inboxes usable throughout, and it also means the decommission date gets set from a realistic export timeline, not from whatever the Mimecast contract renewal happens to be.  

Inactive and leaver mailboxes are carried across too, landing in Purview as inactive mailboxes on the same discovery terms they had in Mimecast, so nobody quietly loses years of a departed employee mailbox.  

Licensing gets checked from the start, rather than just assumed. While E3 covers the storage side of core archiving, if the business needs retention labels or full eDiscovery, E5 can also be scoped before rather after go-live.  

Our approach is also built to help organisations avoid Mimecast’s export and hostage fees, which when left unmanaged can more than double the cost of leaving.  

If you want to find out where your business stands on your own readiness, get in touch with us today!  

Don’t let the decommission date be the first compliance test

A Mimecast to Purview migration is a compliance decision dressed up as a data transfer. Get the archiving, retention and legal hold mechanics mapped and tested properly, and the cutover is genuinely clean. Skip that work, and the decommission date becomes the moment you find out the hard way. 

Run the tips above before a decommission date goes on the calendar; NBConsult run the readiness assessment with you.