Forum Discussion

baschi's avatar
baschi
Level 4
6 years ago

Bulk Exports of PSTs

Dear community,

I'm considering an migration with Enterprise Vault as a source. My challenge is I need to extract the data from the vault archives. I know we could do PST export manually once by once, but know there is also an EV PST Export Wizard where I'm able to select multiple Archives for export. My question is:
In case i select mutliple Archives for export in this wizard, will I get multiple PST files out? So one Pst file per Archive? Or will all archives put into one Pst?

Best Regards,
baschi

  • baschi, the approach to your migration will heavily need to weigh the importance and quantity of data in your archive to migrate. especially if you have journal data. the pst export is typically reserved for 1-off exports and not for mass exodus of data. the export is only half the equasion. where is all the data going to end up? 

  • How to do this best depends on:

    * How many archives you want to process

    * Timescales for the migration

    * How much you want/need in terms of reporting/managability

    * How much you want to spend doing the task

    I'd recommend Archive Shuttle - but then I'm biased :) But it can handle a lot of archives, handle transient and permanent errors easily, and do you some good reporting on progress and final project-completion reporting.

  • Hi,

    yes, they will be split by archives.You should get one or more pst files per archive depending on the size limit that you set in the wizard.

     

    Regards

    Marc

    • GertjanA's avatar
      GertjanA
      Moderator

      don't select too many in 1 go.. slowly build up the amount of archives you select.

      If you're on 12(.3), there is a powershell command available for exporting archives.

      • Prone2Typos's avatar
        Prone2Typos
        Moderator

        This is possible and can meet the needs of some customers but has some serious pain points that results in projects being much more laborious than anticiapted and inheriently running much longer than anticipated. This is the reason there is a strong market for migration vendors, a lot of people start to do something like this and find the level of effort/reporting/monitoring/complexity to make a stew resulting in a much more complicated project than desired. Full disclosure, I am the Product Owner for a (fantastic!!) migraiton solution... but dont let that soil the point.

        I started typing out some pointers, but to be honest they align pretty closely with a blog and checklist I wrote when thinking at some depth on this topic. I did not intend to plug anything but that will give you a more in depth list of stuff to think about when undergoing such a project than I would ad hoc type here.

        Scope and understanding your source are amongst the most important things to nail down early and stick to or formalize exceptions for... as it is the hidden killer in migration projects IMHO. Formalizing how exception handling will be done is up there too....or you will forever burn yoruself to the ground chasing minor failures.