First page of Microsoft's 100,000-partner directory, sorted by responsiveness Microsoft Solutions Partner — Security, Modern Work, Infrastructure, App Innovation Microsoft partner since 2006 1,100+ organizations under management
Home/Services/Third-Party Email Archive Migration to Microsoft 365
Migration

Third-Party Email Archive Migration to Microsoft 365

Moves legacy email archives out of third-party platforms — Mimecast, Veritas Enterprise Vault, Google Vault, Barracuda, Proofpoint, and similar — and into Exchange Online mailboxes and In-Place Archives in Microsoft 365. IT Partner designs the extraction for your specific source platform, documents chain of custody batch by batch, re-creates retention policies and legal holds in Microsoft Purview (holds never transfer by themselves), and closes with an item-count validation report your legal team can rely on. Third-party extraction tooling and vendor export fees are itemized separately in the quote; a typical engagement runs about four weeks, with very large or heavily throttled archives taking longer.

Timeline 4 weeksService owner Roman SotnikExchange OnlineMicrosoft PurviewMicrosoft 365

What this engagement is

Leaving a legacy archive platform is rarely blocked by the mail flow — a gateway or journaling cutover can be done in days. What keeps organizations paying the old vendor for another year is the archive itself: years of messages, often under retention rules or legal hold, sitting in a proprietary store that only leaves at the speed the vendor allows. Every source platform exits differently, and the extraction strategy is most of the engagement. Mimecast archives typically leave as EML or PST exports, or through Mimecast's own paid export service for large volumes. Google Vault exports to MBOX or PST in bounded batches. Enterprise Vault does not really "export" at all at scale — its single-instanced store is normally read by specialist migration tooling, and shortcut (stub) items in user mailboxes have to be rehydrated or cleaned up. Journal archives add a further wrinkle: journaled messages carry envelope data about original recipients that has to be mapped before the content means anything in a per-user mailbox. We have to plan for export formats, throttling, batch sizes, and vendor lead times before the first message moves — so we do, in writing, before you approve anything. The compliance side is just as unforgiving. Retention policies and legal holds are configuration, not data: nothing re-creates them in Microsoft 365 automatically. We inventory every hold and retention rule in the source, agree the equivalent constructs in Microsoft Purview with whoever owns compliance in your organization, implement them before data lands, and keep the old platform readable until reconciliation is signed off. Every extraction batch is logged — counts, sizes, and verification results — so there is a chain-of-custody record from source to destination rather than a shrug. This service covers third-party archive platforms specifically. If your archive data is already in Exchange or Microsoft 365 and just needs to move — server to cloud, or tenant to tenant — that is the In-Place Archive Migration or tenant-to-tenant archive service instead; and if what you have is a pile of PST files, the PST file migration service is the shorter path.

Success criteria

01Every archive in scope is inventoried before extraction begins — mailbox archives, journal archives, and leaver data, with sizes, date ranges, and the holds that apply
02The extraction plan names the export method, formats, tooling, and vendor dependencies for your specific platform, with third-party costs itemized so nothing surprises you mid-project
03Retention policies and legal holds are re-created in Microsoft Purview and verified before the source is switched off — no gap a court or regulator could ask about
04Migrated data lands where it is usable: the right user's mailbox or In-Place Archive, searchable through Outlook and Purview eDiscovery
05A batch-by-batch chain-of-custody log and a final item-count reconciliation report exist, signed off by your named approver
06The legacy platform reaches a documented decommission-ready state — and you stop paying for it

What you receive

Source archive assessment — platform, versions, data volume, item counts where the source exposes them, mailbox vs journal archives, leaver data, and an inventory of retention rules and legal holds
Extraction and ingestion plan — export method and formats, migration tooling, batch sizes, throughput expectations, vendor export dependencies and lead times, and an itemized list of third-party tooling licenses and vendor fees required
Recipient and journal mapping design — where each archive lands (primary mailbox, In-Place Archive, inactive or shared mailbox for leavers), and how journal envelope data maps to custodians
Purview re-creation matrix — every source retention rule and hold, its agreed Microsoft Purview equivalent (retention policies, retention labels, litigation hold or eDiscovery hold), and its implementation status
Chain-of-custody log — per-batch record of export, transfer, ingestion, counts, and verification results
Pilot migration report for an agreed sample set, with fidelity findings before bulk migration is approved
Final validation and reconciliation report — source vs destination item counts, error and exception register with disposition for every skipped item
Legacy platform decommission-readiness statement — what has been verified, what to retain, and what can be switched off

How the work unfolds

Assessment and inventory (week 1)

Read-only review of the source platform: volumes, archive types, custodians, leavers, retention rules, and holds. Destination licensing and mailbox readiness are checked at the same time.

Extraction strategy and compliance mapping (week 1–2)

Export method, tooling, and batch design for your platform; the Purview re-creation matrix agreed with your compliance owner; third-party tooling and vendor export costs itemized for approval.

Destination preparation (week 2)

Licensing verified, In-Place Archives enabled where needed, inactive or shared mailboxes prepared for leavers, and the agreed Purview retention policies and holds implemented before data arrives.

Pilot batch (week 2)

A representative sample is extracted, ingested, and verified end to end — formats, folder mapping, journal handling, and counts — before you approve bulk migration.

Bulk extraction and ingestion (weeks 2–4, volume-dependent)

Batches run continuously within the source platform's export limits, each one logged in the chain-of-custody record with counts and verification results. Progress is reported against the plan, not discovered at the end.

Validation and reconciliation (week 4)

Source-to-destination reconciliation, exception register with a disposition for every skipped or failed item, and searchability spot-checks through Outlook and Purview.

Sign-off and decommission readiness (week 4)

Your approver signs the reconciliation report; we deliver the decommission-readiness statement so the legacy contract can end on evidence, not hope.

Prerequisites

Administrative access to the source archive platform, or a named contact at the vendor if exports run through a vendor service
A Microsoft 365 tenant with Exchange Online, and licensing that supports the destination design — In-Place Archives require Exchange Online Plan 2 or the Exchange Online Archiving add-on; we confirm the exact requirement for your design during assessment
A named compliance or legal owner empowered to approve the hold and retention re-creation matrix
A decision on leavers: which departed employees' archives must be retained, and under what access model
Willingness to keep the source platform readable until reconciliation is signed off — decommissioning early removes the ability to verify

Who does what

IT Partner

  • Assess the source platform and produce the inventory, extraction plan, and itemized third-party cost list
  • Design the recipient, leaver, and journal mapping and agree it with you
  • Implement the agreed retention policies and holds in Microsoft Purview before data lands
  • Run the pilot and the bulk extraction and ingestion batches, maintaining the chain-of-custody log
  • Reconcile source against destination and produce the validation report and exception register
  • Deliver the decommission-readiness statement for the legacy platform

Your team

  • Provide source platform access and, where needed, engage the vendor for export services on your contract
  • Approve the extraction plan, the itemized third-party costs, and the pilot results before bulk migration
  • Nominate the compliance owner and approve the Purview re-creation matrix
  • Decide the leaver retention model and confirm which custodians are in scope
  • Keep the source platform contract alive until reconciliation is signed off
  • Sign the final reconciliation report and own the decommission decision

What's not included

Third-party extraction or migration tooling licenses and source-vendor export fees — these are itemized separately in the quote and contracted transparently, never buried in our fee
Journaling redesign — if you journal to the old platform today, we point you at the right Microsoft-side answer during assessment, but designing a new journaling or compliance-capture architecture is its own engagement
eDiscovery case work — running searches, reviews, or productions over the migrated data is the Purview eDiscovery Search Assistance service
Broader retention and records-management design beyond re-creating what the source enforced — for a proper lifecycle program, see Microsoft Purview Data Lifecycle Management Implementation
Microsoft 365 licenses for the destination — we tell you exactly what the design requires; the subscriptions are purchased under your agreement
Migration of non-email content (files, Teams, chat archives) — scoped separately if your platform holds it
Replacement of the email security gateway itself — moving your filtering from Mimecast or Proofpoint onto Microsoft's stack is its own project: see Mimecast or Proofpoint to Defender for Office 365 Migration. Together, the gateway move and this archive migration are the complete exit

Limitations & technical notes

!Extraction speed is governed by the source platform, not by us. Vendor export services have queues and lead times, APIs are rate-limited, and per-GB economics differ enormously between platforms — which is exactly why this service is quoted per engagement rather than at a flat per-GB price.
!Legal holds and retention policies cannot be moved, only re-created. We implement the agreed Purview equivalents before data lands and keep the source readable until sign-off, but the mapping between two vendors' retention semantics is an approximation your compliance owner must approve — we will not silently decide it for you.
!Journal archives do not map one-to-one to mailboxes. Reconstructing per-custodian views from journaled mail depends on envelope data quality, and the mapping decisions (including for distribution-list recipients) are documented for your approval rather than assumed.
!Fidelity follows the export format: folder structure, flags, and some metadata may not survive every source's export path identically. The pilot batch exists to make these limits visible on your real data before bulk migration.
!Enterprise Vault shortcuts (stubs) left in user mailboxes are a separate cleanup decision — migrating the archive does not remove them, and we scope stub handling explicitly during assessment.
!The four-week shape assumes the source cooperates. Multi-terabyte archives, vendor export queues, or litigation constraints extend the schedule, and the plan says so up front rather than at week four.
!Departed employees' data typically lands in inactive or shared mailboxes; the licensing and access model for leavers is agreed during assessment, not defaulted.

Frequently asked questions

Which archive platforms do you migrate from?

Mimecast, Veritas Enterprise Vault, Google Vault, Barracuda, and Proofpoint archives are the common cases; the approach — assess, plan the extraction, pilot, migrate in logged batches, reconcile — applies to other archivers too. Each platform has a genuinely different exit path, which is why the assessment names the method and tooling for yours specifically before anything is approved.

How does the data actually get out of Mimecast?

Typically as EML or PST exports, either self-service in batches or through Mimecast's own paid export service for larger volumes — the vendor route is priced per gigabyte on your Mimecast contract and has a queue, which we build into the schedule. The extraction plan states which route fits your volume and itemizes the vendor cost separately, so you see it as Mimecast's line, not hidden in ours.

What does chain of custody mean in this service?

A written, batch-level record from export to verification: what was extracted, when, in what format, what was ingested where, the item counts at each step, and the verification result. Combined with the final reconciliation report and the exception register, it gives your legal team a defensible account of the move — the thing that is impossible to reconstruct after the old platform is switched off.

What happens to our legal holds?

They are inventoried, mapped to Microsoft Purview equivalents — litigation hold or eDiscovery holds for custodians, retention policies and labels for rules — and implemented in the destination before data lands. Nothing migrates a hold automatically, so this is deliberate, documented work your compliance owner signs off. The source stays readable until reconciliation is complete, so there is no window where held data exists nowhere enforceable.

Our archive is a journal archive. Why is that harder?

Journaling captures one copy of every message with an envelope wrapper recording the true recipients, including BCC and distribution-list members. To make that meaningful in Microsoft 365, envelope data has to be read and each message attributed to the right custodians — decisions with real compliance weight, especially for leavers and lists. We document the mapping rules and get them approved rather than letting a tool guess.

Where does the migrated data end up?

Wherever it is most usable under your compliance rules — usually each user's In-Place Archive, so old mail is searchable in Outlook without swelling the primary mailbox, with leavers going to inactive or shared mailboxes. Once in Microsoft 365, everything is subject to Purview retention and searchable through eDiscovery. The mapping design puts the destination for every custodian in writing before migration.

What Microsoft 365 licensing do we need?

In-Place Archives require Exchange Online Plan 2 or the Exchange Online Archiving add-on, and hold and retention features depend on your plan level. Rather than list every SKU permutation here, the assessment states exactly what your destination design requires against what you already own — often the licensing you have is already enough.

What about employees who left years ago?

Their data is often the main reason the archive exists, so leavers get an explicit decision, not a default: retained in inactive mailboxes, consolidated into shared mailboxes, or excluded with your sign-off. The assessment lists every leaver archive it finds, and the mapping design records what you chose for each.

Why does this take weeks when the data is just email?

Because the bottleneck is the source. Export services have queues, APIs are throttled, and journal archives need mapping before ingestion — none of which is fixed by us working harder. The typical engagement runs about four weeks; the assessment gives you a schedule grounded in your platform's real export behavior, and the batch log shows progress continuously rather than asking you to trust the plan.

How do you prove nothing was lost?

Reconciliation, not reassurance: per-batch counts in the chain-of-custody log, a final source-to-destination comparison, and an exception register in which every skipped or failed item has a stated reason and disposition. You sign the reconciliation report before we call the migration done — and before anyone talks about decommissioning the source.

Can we keep searching the old archive during the migration?

Yes, and you should — the source stays live and readable until reconciliation is signed off. That overlap is a deliberate safety property: it preserves your search capability, keeps held data enforceable somewhere at every moment, and gives the reconciliation something to reconcile against. The cost of a few extra weeks of the old contract is the cheapest insurance in the project.

Is this the same as your In-Place Archive Migration service?

No. In-Place Archive Migration and the tenant-to-tenant variant move Exchange archive mailboxes between Exchange environments and Microsoft 365 tenants using Microsoft's native migration paths. This service handles third-party archive platforms, where the hard work is getting data out of a proprietary store and rebuilding compliance settings — a different problem with different tooling and economics.

We have active eDiscovery cases against the old archive. Can we still migrate?

Usually yes, with sequencing: custodians and data attached to active matters are identified in the assessment, their holds are re-created in Purview first, and where a matter is genuinely mid-production your legal team may keep that slice in the source until the case allows. Ongoing search and case work over the migrated data is its own service — Purview eDiscovery Search Assistance — and we hand over cleanly to it.

Didn’t find your question?

Ask it here. A real engineer answers by email within one business day — and if it’s a good one, it becomes part of this page so the next person finds it.

Answered by a person, one time, to your inbox. Nothing you type here is published without a human reviewing and anonymizing it first.

Often combined with

Contact us for a quote
4 weeks
Get an archive migration quote