Bulk Migrating Data from Enterprise Vault.cloud
If you’ve read any of my other blogs, you’ll know I’m no big fan of vendor lock-in.
My ‘beef’ is that if customer has paid to store its data with a supplier for years, they should be able to get that data back out again without the exit process itself becoming a major project, AND without exorbitant exit costs.
That is why the current position with Enterprise Vault.cloud is getting my goat (to say the least).
EV.cloud has been through a fair amount of corporate change in a short space of time – moving from Veritas into Arctera in late 2024, before Arctera itself was acquired by Cloud Software Group in December 2025.
One of the unfortunate by-products of acquisitions and restructures like these is that new owners can make decisions that materially change the service customers originally signed up for – including removing options that had previously made it easier to leave.
This could be what has happened when it comes to extracting data out of EV.cloud.
Even if you are prepared to pay for a serviced extraction, that service has now been withdrawn. Arctera no longer offers the bulk export service that customers could previously use to get their data out when leaving the platform.
Whatever the reason for the change, if you’re the customer trying to leave, it does feel a bit like the shutters have come down.
The vendor would no doubt argue that the data is still yours, and you can still access it using Arctera eDiscovery. https://docs.arctera.com/us/en/arctera-ediscovery/about-arctera-ediscovery.html
The problem is that there is a big difference between being able to retrieve a bit of data when you need it, and being using this tool to carry out a full-scale data extraction from EV.cloud.
The analogy is that it’s like digging an escape tunnel with a teaspoon.
The problems with Arctera eDiscovery when it comes to extraction from EV.cloud
If using Arctera eDiscovery is now the only vendor-endorsed route for getting data out of EV.cloud, here are some of the practical challenges you can expect if you try to use it for a full DIY migration:
Export limits
Arctera documentation states that a maximum of 200,000 messages can be exported at one time.
If you are dealing with exporting millions of messages, this limit means someone has to split the archive into manageable searches, run and monitor them, deal with searches that exceed the limit, rerun failed jobs, download the results and keep track of exactly what has already been processed.
For example, “Search for emails between these dates: ‘01 January 2022 to 08 January 2022’”, or for large enterprises, you may need to run a search that is limited to just a day at a time.
The risks are obvious: gaps, overlaps, duplicate exports or simply losing track of where you are.
Handling what you’ve exported
When you export from using the eDiscovery service, the results are written into PST, EML or MSG files. You’ll end up with LOADS of these, and they all need to be stored securely, catalogued, reconciled with the searches that produced them, and then ingested into the target.
As you can imagine, with a large archive, provisioning interim storage and handling all these files can become a sizeable exercise in its own right.
Deciding what to migrate and where
One of the challenges of an Enterprise Vault migration is deciding what should go where – but it is also an opportunity to clean up the archive and make better use of Microsoft 365.
For active users, you might choose to move older email into the user’s Exchange Online Archive mailbox, while keeping more recent content in the primary mailbox.
Leavers need a different approach. If they no longer have an active mailbox, you need to decide whether their archived data still needs to be retained and, if so, where it should live. That might mean an inactive mailbox, or a shared mailbox.
Licensing considerations also come into the mix, particularly around archive mailboxes, retention and inactive mailboxes.
Migrating journal data into Microsoft 365
EV.cloud was often used as a journal archive for compliance purposes, not simply as a repository for individual users’ archived mail.
Given that Microsoft 365 does not have a conventional journal store ‘as is’, this data does not necessarily have an obvious one-for-one destination.
Our Migrating Journals to Microsoft 365 video is pretty ancient these days, but it still gives a useful, and rather more entertaining than usual, explanation of why traditional journal data needs some thought before being moved into Microsoft 365.
The ‘people and time’ factor
If your EV.cloud contract is approaching renewal, the key question is not whether the data can be exported. It is how long it will take to get all of the required data out, checked and safely into its new home.
With a manually driven eDiscovery process, you also need to factor in the ‘grunt work’ involved.
Someone has to build and monitor searches, deal with failed or oversized jobs, rerun them, download and catalogue the results, and keep track of what has already been processed.
Then the exported data has to be stored securely, checked and prepared for ingestion (see my earlier point about handling what you’ve exported).
None of this is especially difficult on its own, but across many hundreds of export jobs it can become a significant operational burden and not necessarily something you’d want to saddle one or more of your IT team members with (assuming you value their sanity).
This is where we can help
A DIY eDiscovery export may be perfectly sensible if you have a relatively small amount of data to retrieve. A complete EV.cloud migration is another matter.
Essential has been working with email archives and archive migrations for more than 25 years, and we have completed hundreds of migration projects, including complex, highly regulated and large-scale environments.
We can help you work out:
- Where the different data populations should go in Microsoft 365
- How much data actually needs to come out
- What can legitimately be left behind (to save you time and money)
- How the archive should be broken down for extraction
- How leavers and inactive users should be handled
- How journal data should be treated
- ….along with many other considerations that may be very specific to your organisation and data management needs.
The difference working with Essential
We are realistic about timelines
The fact that a migration platform can theoretically ingest data at a particular speed is not much help if extracting it from the source becomes the bottleneck.
At Essential, we prefer to work out what the achievable extraction rate looks like using the customer’s own environment and data. From that, we can give a realistic estimate of how long the exit is likely to take.
If the answer is nine months rather than the six months you were hoping for, it is much better to know that before you commit to the exit timetable.
We offer a good price
Because Essential handles multiple migration projects in parallel you only pay for the hours we are working on your project – not the time waiting for a task to finish before we start the next task, nor the elapsed time on the project.
A few hours per day is typical.
